AskSin++ Library

[papa]

Nö - denke nicht. Kannst Du bitte mal nen PullRequest fertig machen?

[jp112sdl]

Sind irgendwelche Nebenwirkungen davon zu erwarten, dass jetzt kein Hardware-Interrupt-Pin benutzt wird?

Nö - denke nicht. Kannst Du bitte mal nen PullRequest fertig machen?

Nur für mein Verständnis:
- Verwendung eines beliebigen Pins: Wenn ein Interrupt auftritt und der Sketch gerade irgendwo wartet (delay(...)), würde dieser beim Pinpolling verloren gehen, falls die Haltezeit des Pegels kürzer war, als das delay.
- Verwendung eines Hardware-Interrupt-Pins: der AVR merkt intern jederzeit das Auftreten einer Flankenänderung und löst in jedem Fall die hinterlegte ISR aus

[Tom Major]

Nur für mein Verständnis:
- Verwendung eines beliebigen Pins: Wenn ein Interrupt auftritt und der Sketch gerade irgendwo wartet (delay(...)), würde dieser beim Pinpolling verloren gehen, falls die Haltezeit des Pegels kürzer war, als das delay.
- Verwendung eines Hardware-Interrupt-Pins: der AVR merkt intern jederzeit das Auftreten einer Flankenänderung und löst in jedem Fall die hinterlegte ISR aus

Wo hast du diese Info her?
Nach meinem Verständnis kann ein delay() einen Pin Change Interrupt (PCINT) nicht verloren gehen lassen.

Unterschiede EXINT - PCINT nach meinem Verständnis:
- historisch gewachsen, EXINT war schon bei den frühen Devices da, PCINT kam später
- EXINT hat mehr Config Möglichkeiten (level)
- EXINT hat eigene ISR Vektoren, PCINT hat shared Vektoren, dort muss geschaut werden welcher Pin es war (aber nicht per Pin-polling sondern gespeichertes Interrupt bit)
- EXINT kann alle Sleep modes aufwecken (nur level), PCINT nur Idle Edit: PCINT auch

[jp112sdl]

Wo hast du diese Info her?

Das war mein eigenes Gedankenkonstrukt mit Informationen von hier:
https://www.arduino.cc/reference/de/language/functions/external-interrupts/attachinterrupt/

Interrupts sind nützlich, um bestimmte Tasks in Microkontrollerprogrammen automatisch ablaufen zu lassen und können helfen, Timingprobleme zu lösen.
...
Wenn du z.B. sicherstellen willst, dass das Programm alle Stromimpulse eines Drehgebers messen kann, wäre es sehr schwer ein Programm zu schreiben, das noch andere Aufgaben zusätzlich erfüllt, weil das Programm sonst immer den Sensor pollen (d.h. permanent abfragen) müsste.

Ich hatte mal bei einem Pulszählerprojekt Probleme, dass Pulse verloren gingen, wenn ich nicht die INT Pins benutzt habe.
Ist aber auch schon wieder ein paar Jahre her.

[Tom Major]

Das mit dem delay() bezieht sich darauf dass es nicht innerhalb einer ISR funktioniert.
Eine PCINT Erkennung wird in PCIFR geflagt und sollte nicht verloren gehen.
Wenn der uC allerdings in einer anderen ISR beschäftigt ist und in der Zeit kommt der PCINT 2x, dann wirst du eine Zählung verlieren. Ist aber bei EXINT auch nicht anders.

Was mir gerade einfällt, mit dem neuen WOR im cc1101, kann es da den Fall geben dass der uC über /INT0 geweckt werden soll?
Falls ja, dies wird nicht bei PCINT funktionieren falls wir im power-down/power-save Mode sind.

[jp112sdl]

Falls ja, dies wird nicht bei PCINT funktionieren falls wir im power-down/power-save Mode sind.

Und wie ist das bei den RC-Sketchen?
Die Taster wecken den AVR dort ja an jedem beliebigen Pin!?

[Tom Major]

Gute Frage. war heute zu flüchtig beim Drüberschauen.
Tabelle 14.2. Sleep Modes, da steht bei den Wake-up Sources

Code Auswählen Erweitern

3) For INT1 and INT0, only level interrupt.
PCINT kann aufwecken, nur EXINT nicht als change sonder nur level.
Also alles gut fürs wake-up. 

[Psi]

Hi,
wie kann ich einen Dimmer-Kanal in der setup() Methode nach dem Booten des AVR auf einen bestimmten Wert stellen, optimalerweise mit Ramp?

PS: Ich hab schon das eine oder andere Probiert aber iwie tuts nicht wie erwartet.

[papa]

Das sollte mit

Code Auswählen Erweitern

sdev.channel(1).set(value, ramp, delay);
gehen.

[Psi]

Das sollte mit

Code Auswählen Erweitern

sdev.channel(1).set(value, ramp, delay);
gehen.

Vielen dank für die schnelle Antwort. genau so hab ich das gemacht aber iwie is das nicht rund.
value: Steps (also 0..200)
ramp: Millisekunden? Das ist doch die Zeit des Dimmvorgangs?
delay: 0

Code Auswählen Erweitern


setup() {
   ...
  sdev.initDone();
  sdev.channel(1).set(200, 500, 0);
}


Code Auswählen Erweitern


AskSin++ V4.1.2 (Jan 20 2020 21:55:14)
Address Space: 32 - 843
CC init1
CC Version: 04
- ready
Config Freq: 0x2165AA
SetLevel: 00 0000 FFFF
SetLevel: 00 0000 FFFF
SetLevel: 00 0000 FFFF
ID: 11125A  Serial: konstant22
SetLevel: C8 01F4 0000
Ramp/Level: 0/200
Ramp/Level: 50/0


[papa]

Mach mal delay auf 0xffff

[Psi]

Mach mal delay auf 0xffff

Vielen Dank, mit

Code Auswählen Erweitern


sdev.channel(1).set(200, 0b01100001, 0xffff);

tut es nun. Ganz verstehe ich es aber nicht.

Die Funktion erklärt sich mir nicht ganz: https://github.com/pa-pa/AskSinPP/blob/master/AskSinPP.h#L112
Die linken 3 Bits geben die Ramp zurück und sie wird verdoppelt wenn eins der rechten 5 Bits gesetzt ist?

Warum setz ich delay auf 0xFFFF? Naiv würde ich annehmen, dass ich dann eben so lange warte.

[jp112sdl]

Die linken 3 Bits geben die Ramp zurück und sie wird verdoppelt wenn eins der rechten 5 Bits gesetzt ist?

Wenn du 0xFFFF übergibst, wird direkt 0xFFFFFFFF zurückgegeben: AskSinPP.h#L114

Die Funktion erklärt sich mir nicht ganz
Die linken 3 Bits geben die Ramp zurück und sie wird verdoppelt wenn eins der rechten 5 Bits gesetzt ist?

Die Zeitberechnung, wie sie in den XML Files verwendet wird, war für mich als "nicht-Informatik-oder-Mathe-Student" auch nicht sofort klar zu verstehen:

Code Auswählen Erweitern


<parameter id="RAMP_TIME" operations="write" control="NONE">
  ...
  <conversion type="integer_tinyfloat" mantissa_start="5" mantissa_size="11" exponent_start="0" exponent_size="5"/>
</parameter>

und musste mich erstmal belesen, was es mit Mantisse und Exponent auf sich hat 

[papa]

Die Zeitumrechnung habe ich auch nur von der NewAskSin geerbt

[Tom Major]

hatte auch schon die "alte" AskSin ähnlich drin:
https://github.com/trilu2000/AskSin/blob/master/utility/Helpers.cpp#L41