Arduino IDE: Init-Ort von Lib/Device

Nik A. schrieb:

Wenn ich das gleiche für Atmega644 kompiliere, hängt sich der µC sofort auf, sobald BL0940 bl0940; aufgerufen wird.

Du wirst Dir den /Konstruktor/ der Klasse BL0940 ansehen müssen. Dessen Deklaration wirst Du in der zugehörigen *.h-Datei finden, und dessen Definition entweder auch dort oder in der zugehörigen *.cpp-Datei.

Der Konstruktor einer Klasse wird aufgerufen, sobald ein Objekt dieser Klasse angelegt wird.

Legst Du Deine Objektinstanz als globale Variable (d.h. außerhalb eines Funktionsrumpfes) an, wird der Konstruktor aufgerufen, bevor irgendeine andere Funktion Deines Programmes aufgerufen wird.

Hallo,

im Ordner "Sketchbook" gibt es einen Unterordner "libraries". Dorthin gehören alle neu hinzugefügten Libs. Installiere eine über die IDE Bibliotheksmanager, dann siehst du das Schema F.

Wenn ich das gleiche für Atmega644 kompiliere, hängt sich der µC sofort auf, sobald BL0940 bl0940; aufgerufen wird.

Der µC kann sich nicht aufhängen, weil der dein Programm noch nicht hat. Du meinst bei der Kompilierung bekommst du Fehlermeldungen? Schön.

Das nackte #include funktioniert?

1

BL0940 bl0940;

Hiermit erzeugst du eine Instanz. Ob das so richtig ist weiß ich nicht. Ich weiß ja nicht einmal was du alles geändert hast. Eigentlich weiß ich gar nicht was du überhaupt gemacht hast. Viel Text ohne eine wirklich verwertbare Information. Mit geänderten IDE Einstellungen siehst du mehr was schief läuft.

Gegenfrage. Wenn du nicht beteiligt bist und du liest deinen eigenen Text, weißt du dann Bescheid was der TO meint und was er so gemacht hat?

@Harald K.: uff :) ich hab die 2 files in der IDE offen, aber warum funktioniert es denn für ESP32 und nicht für atmega(mightcore)?

@Veit D.: nein, ich meinte den µC. Beim Compilen hängt sich nix auf, das läuft perfekt durch. Die Lib kann ich über den Manager nicht laden und will ich auch nicht, da ich für jeden µC den Code darin anpassen muss, da die entsprechende UART z.B. unterschiedlich ist.

Noch mal um Missverständnisse zu beseitigen: unter o.g. URL findet sich das Beispiel, das habe ich testweise einmal für ESP32 und einmal für atmega644 kompiliert, aber jeweils die richtige UART eingetragen.

Beides kompiliert, aber der atmega hängt sich auf. (kann man ja schön mit seriellen Test-Ausgaben rausfinden. Diese habe ich auch in jeder Funktion in der Lib eingebaut und da triggert keine einzige, wenn beim Atmega die Instanzerzeugung vor der Setup-Routine steht. Sobald die dort drin steht, sieht man, welche Funktionen ausgelöst werden.)

Schreibe ich den Konstruktor/die Erzeugung der Instanz aber in die Setup-Routine, (inclusive der Zeilen für Reset und Netzfrequenz, die im Beispiel stehen), dann läuft es. Aber nur solange, wie ich in der Loop dann nicht Abfragen starte, denn dort existiert dann die Instanz nicht mehr, die nur im Setup-Block steht.

Es muss also irgendwo einen Unterschied zwischen ESP32 und mightycore geben.

Soweit ich sehen kann, wird die Setup-Routine nicht ausgelöst, wenn beim atmega die Instanzerzeugung vor dem Setup steht, wie es im Beispielcode für ESP32 der Fall ist.

Ganz ausführlich: Steht im Setup nur

Serial.begin(115200); Serial.println("blah");

dann erscheint kein blah, wenn die Instanzerzeugung außerhalb steht. Steht sie drin, geht es, ebenso auch die Kommunikation mit dem BL0940.

Nik A. schrieb:

Ganz ausführlich: Steht im Setup nur Serial.begin(115200); Serial.println("blah"); dann erscheint kein blah, wenn die Instanzerzeugung außerhalb steht. Steht sie drin, geht es, ebenso auch die Kommunikation mit dem BL0940.

Die Bibliothek ist so geschrieben, dass der uC mit dem BL0940 über eine serielle Schnittstelle mit 4800 Baud kommuniziert. Der Atmega644 hat nur eine solche Schnittstelle. Wenn diese eine Schnittstelle für die Kommunikation mit dem Sensor benutzt wird, dann darfst du sie nicht auch noch für Testausgaben benutzen.

LG, Sebastian

@Sebastian: stimmt, ich hab ein Detail vergessen zu erwähnen: es ist ein atmega644A, der hat 2 UARTS und die gehen beide.

Wie gesagt, ich hab die Uarts und alle Code-Teile getestet. Die gehen, lediglich die Instanzerzeugung für den BL0940 macht Probleme.

Die ESP32-Schaltung mit Code funktioniert perfekt, ich will das nur auf atmega644A portieren, den ich auch immer wieder verwende (mit 2 hardware-UARTS) und besser schützen kann. Ich hatte nur noch nie das beschriebene Problem in den letzten >18 Jahren :> Vorallem, weil es keine Compile-Fehler gibt :o

Nik A. schrieb:

Wie gesagt, ich hab die Uarts und alle Code-Teile getestet. Die gehen, lediglich die Instanzerzeugung für den BL0940 macht Probleme.

Vielleicht hülfe ja ein Zeiger?

1

BL0940* bl0940 = NULL; 

2

3

void setup() {

4

    bl0940 = new BL0940();

5

    bl0940->Reset();

6

}

Ein T. schrieb:

Vielleicht hülfe ja ein Zeiger?

Das setzt eine dynamische Speicherverwaltung auf dem AVR voraus, und ohne sich den Konstruktor der Klasse anzusehen, weiß man nicht, wieviel Speicher diese Klasse benötigt.

Vielleicht einfach zu viel für den AVR?

Nik A. schrieb:

Wie gesagt, ich hab die Uarts und alle Code-Teile getestet. Die gehen, lediglich die Instanzerzeugung für den BL0940 macht Probleme.

Der Konstruktor BL0940::BL0940 ruft Serial2.begin(4800) auf. Was passiert, wenn du im Bibliothekscode diese Zeile in die BL0940::Reset-Methode verschiebst?

LG, Sebastian

Harald K. schrieb:

ohne sich den Konstruktor der Klasse anzusehen, weiß man nicht, wieviel Speicher diese Klasse benötigt

Es gibt eine Fehlerbehandlung. Im einfachsten Fall bekommt man bei new einen Nullpointer zurück der einem mitteilt dass etwas schief geaufen ist.

Also ob es funktioniert (passt) oder nicht bekommt man durch die trial-and-error-Methode heraus.

..

(Streichen)

Ich hab weiter experimentiert:

ich habe die Inhalte der cpp/h-Dateien einfach unten an den Sketch angehangen und entsprechend umbenannt. also alles BL0940:: wurde zu BL0940_

die Funktionen entsprechend angepasst und die Variablen/Defs ganz nach oben an den Anfang.

Was ist passiert? Die Comm mit dem IC funktioniert auf einmal ... Ich hab keine Erklärung.

Wie es aussieht, kommt es gar nicht erst bis zum .reset(), da passiert schon nichts mehr :o

warum der Downvote auf ein Posting mit Fakten bzw. Beobachtungen? typisch mikrocontroller.net XD

Nik A. schrieb:

warum der Downvote auf ein Posting mit Fakten bzw. Beobachtungen? typisch mikrocontroller.net XD

Das ist ein Bot, einfach nicht beachten.