ina219.getCurrent_mA(); Funktion in der ISR nicht aufrufbar

[Sandro N. (nick2245)]

Ich habe einen Arduino Nano und ein INA219 Strommessmodul.
Ich möchte über die TimerOne.h Bibliothek einmal die Sekunde den 
Stromwert auslesen.
Hierzu wird 1 mal die Sekunde die ISR per Timer mit dem Namen Strom 
aufgerufen.
Normalerweise sollte der Befehl zum abfragen " I = 
ina219.getCurrent_mA(); " in der ISR mit dem Namen Strom stehen.  Da 
funktioniert er aber nicht und der Arduino Nano stützt ab.
Zum Testen habe ich mal versucht eine andere Methode in der ISR 
aufzurufen. Das geht. Es scheint also ein Problem mit dieser einen 
Funktion zu sein.
Weiß jemand warum ich gerade diese Funktion nicht aufrufen kann aber 
andere Sachen schon?

#include <TimerOne.h>
#include <Wire.h>
#include <Adafruit_INA219.h>
Adafruit_INA219 ina219;

int I = 0;                          //Stromwert

void setup(void){
ina219.begin();
Timer1.initialize(1000000);         //Timer auf 1 Sekunden stellen
Timer1.attachInterrupt(Strom);      //ISR Strom wird jede Sekunde aufgerufen
Serial.begin(115200);
}
void loop(void){   
I = ina219.getCurrent_mA();         //hier wird die Funktion aufgerufen
delay(1000);
Serial.println("Läuft noch");
}
void Strom(void){
//I = ina219.getCurrent_mA();       //hier wird die Funktion nicht aufgerufen.Warum?
Serial.println(I);
}

[Stefan F. (Gast)]

Frage doch mal den Autor der INA Klasse, wenn du die Antwort nicht im 
Quelltext der Klasse findest. Du könntest deine Frage dort abladen: 
https://github.com/adafruit/Adafruit_INA219/issues

[Peter D. (peda)]

Sandro N. schrieb:
> Weiß jemand warum ich gerade diese Funktion nicht aufrufen kann

Vermutlich wird diese Funktion selber einen Interrupt benutzen, aber die 
sind ja innerhalb eines Interrupts gesperrt (der AVR kann kein Nesting). 
Also wartet sie ewig.
Das sollte aber auch in der Doku zu dieser Funktion stehen.

[Stefan F. (Gast)]

Generell ist es eine riskante Sache, aus Interrupts heraus Funktionen 
aufzurufen, die extern kommunizieren oder viel Speicher belegen. Dein 
Serial.println() halte ich dort ebenfalls für eine ganz schlechte Idee.

Denn Interrupts können andere Funktionen unterbrechen, die bereits viel 
Speicher belegt haben. RAM ist bei den kleinen AVR Mikrocontrollern 
knapp bemessen.

[Sascha W. (sascha-w)]

Hallo,

auch wenn das hier warscheinlich nicht das Problem ist, solltest du 
Objekt so initialisieren das sie zum Aufrufzeitpunkt auch verfügbar 
sind.
Serial.begin() sollte also noch vor der Timer1.attachInterrupt() stehen, 
sonst könnte die ISR mit Serial.print() noch vor Serial.begin() 
ausgeführt werden.

Bekommst du vom Compiler irgendwelche Warnungen?

Sascha

[Sandro N. (nick2245)]

Stefanus F. schrieb:
> Dein
> Serial.println() halte ich dort ebenfalls für eine ganz schlechte Idee.

Da hast du recht, das steht da auch nur zum Testen ob I = 
ina219.getCurrent_mA(); ausgeführt worden ist.

[Sandro N. (nick2245)]

Sascha W. schrieb:
> solltest du
> Objekt so initialisieren das sie zum Aufrufzeitpunkt auch verfügbar
> sind.

Da hast du grundsätzlich recht aber wie du schon geschrieben hast spielt 
das hier keine rolle :-)

Achso, und ich bekomme keine Probleme beim Compiler .

[Stefan F. (Gast)]

Sandro N. schrieb:
> das steht da auch nur zum Testen

Dachte ich mir schon.

[Einer K. (Gast)]

Sandro N. schrieb:
> Sascha W. schrieb:
>> solltest du
>> Objekt so initialisieren das sie zum Aufrufzeitpunkt auch verfügbar
>> sind.
>
> Da hast du grundsätzlich recht aber wie du schon geschrieben hast spielt
> das hier keine rolle :-)
>
> Achso, und ich bekomme keine Probleme beim Compiler .

Aber, das Problem, hast du jetzt verstanden, oder?

[Brain 2.0 (Gast)]

Und warum überhaupt per IRQ ?
1 sek ist doch nicht zeitkritisch, das geht auch wunderbar in der loop.

[Sascha W. (sascha-w)]

Brain 2.0 schrieb:
> Und warum überhaupt per IRQ ?
> 1 sek ist doch nicht zeitkritisch, das geht auch wunderbar in der loop.
Oder besser noch, im IRQ ein Flag setzen und in der Loop darauf 
reagieren. In Loop darf dann natürlich kein delay vorkommen.

Sascha

[Stefan F. (Gast)]

Sascha W. schrieb:
> Oder besser noch, im IRQ ein Flag setzen und in der Loop darauf
> reagieren.

Dann kannst du auch gleich den millis() Timer benutzen.

[Brain 2.0 (Gast)]

Sascha W. schrieb:
> Oder besser noch, im IRQ ein Flag setzen und in der Loop darauf
> reagieren. In Loop darf dann natürlich kein delay vorkommen.

Ok....aber besser sehe ich nicht.
Hier braucht man keinen IRQ.

[Sandro N. (nick2245)]

Sascha W. schrieb:
> Oder besser noch, im IRQ ein Flag setzen und in der Loop darauf
> reagieren. In Loop darf dann natürlich kein delay vorkommen.

ja, so habe ich das jetzt auch gelöst. Ich musste nur sicherstellen, 
dass der Code in einer Stunde genau 3600 mal ausgeführt wird.
Solange der Loop nicht länger als 1 Sekunde braucht sollte das auch 
funktionieren.
Ich hatte mich schon gefragt wozu so ein "Job Flag" gut sein soll. Mann 
kann ja alles in die ISR schreiben dachte ich. Aber in meinem Fall ging 
es eben doch nur über eine "Flag".

[Irgend W. (Firma: egal) (irgendwer)]

Sascha W. schrieb:
> Brain 2.0 schrieb:
>> Und warum überhaupt per IRQ ?
>> 1 sek ist doch nicht zeitkritisch, das geht auch wunderbar in der loop.
> Oder besser noch, im IRQ ein Flag setzen und in der Loop darauf
> reagieren. In Loop darf dann natürlich kein delay vorkommen.
>
> Sascha

Oder in der IRQ erst den ADC-Wert sichern und dann den ADC neu starten.
So bracht man nicht Warten bis der ADC fertig ist, dar hat dann fast 
eine Sekunde zeit um fertig zu werden. Die Werte sind dann zwar eine 
Sekunde alt, dafür aber nirgends Wartezeiten wegen dem ADC. Und in 
etlichen Anwendungsfällen ist das durchaus langt das durchaus.

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Sandro N. schrieb:
> Solange der Loop nicht länger als 1 Sekunde braucht sollte das auch
> funktionieren.
Für mich enthält eine main()-Loop, die mehr als 50ms(*) braucht, schon 
einen Fehler. Denn dort drin wird zyklisch alles abgearbeitet, was 
während des letzten Durchlaufs in den Interrupts so angefallen ist.

(*) je nach Anwendung 10..100ms