Status von PhaseCut Dimmer

Entwicklung und Bau von Hardware aller Art, die im HM-Umfeld eingesetzt werden kann

Moderator: Co-Administratoren

papa
Beiträge: 705
Registriert: 22.05.2018, 10:23
Hat sich bedankt: 24 Mal
Danksagung erhalten: 120 Mal

Re: Status von PhaseCut Dimmer

Beitrag von papa » 10.12.2020, 11:52

PhaseCut habe ich nicht gemacht - das kam von extern.
Keine Ahnung, was davon wirklich gebraucht wird.
Anfragen zur AskSin++ werden nur im Forum beantwortet

jp112sdl
Beiträge: 12115
Registriert: 20.11.2016, 20:01
Hat sich bedankt: 848 Mal
Danksagung erhalten: 2150 Mal
Kontaktdaten:

Re: Status von PhaseCut Dimmer

Beitrag von jp112sdl » 10.12.2020, 11:53

TomMajor hat geschrieben:
10.12.2020, 11:32
Macht aber nur Sinn wenn wirklich was dazwischen passiert.
Jup, deshalb war ich verwirrt.

Und vor allem, dass nur cli() ohne anschließendem sei() erfolgt.

Oder sehe ich es richtig, dass mit SREG = oldSREG; der Aufruf von sei() unnötig ist, da Interrupts wieder aktiviert würden, sofern sie es vorher (uint8_t oldSREG = SREG;) waren?

VG,
Jérôme ☕️

---
Support for my Homebrew-Devices: Download JP-HB-Devices Addon

TomMajor
Beiträge: 1793
Registriert: 30.08.2017, 23:25
Hat sich bedankt: 175 Mal
Danksagung erhalten: 399 Mal
Kontaktdaten:

Re: Status von PhaseCut Dimmer

Beitrag von TomMajor » 10.12.2020, 12:06

jp112sdl hat geschrieben:
10.12.2020, 11:53
TomMajor hat geschrieben:
10.12.2020, 11:32
Macht aber nur Sinn wenn wirklich was dazwischen passiert.
Jup, deshalb war ich verwirrt.

Und vor allem, dass nur cli() ohne anschließendem sei() erfolgt.

Oder sehe ich es richtig, dass mit SREG = oldSREG; der Aufruf von sei() unnötig ist, da Interrupts wieder aktiviert würden, sofern sie es vorher (uint8_t oldSREG = SREG;) waren?
Genau so ist es.
Du willst kein sei() da die Interrupts ja global disabled sein könnten, du willst nur "neutral" wiederherstellen.
Viele Grüße,
Tom

fry
Beiträge: 11
Registriert: 08.12.2020, 10:39
System: CCU

Re: Status von PhaseCut Dimmer

Beitrag von fry » 10.12.2020, 16:43

Sooo, hab noch ein wenig rum getestet:
Die cli() Geschichte scheint ein überbleibsel zu sein, macht keinen Unterschied.

Hab jetzt auch noch ein paar andere Versionen getestet:
- Arduino 1.8.12 & 1.8.13
- EnableInterrupt war immer V1.1.0
- AsksinPP sowohl V4 alsauch aktuellen Master

Board Setting:
Arduino Pro/ProMini
Atmega 328P (3.3V/8MHz)

In PhaseCut.cpp hab ich die Funktion die der Interrupt called deaktiviert

Code: Alles auswählen

	void ZeroCrossEventCaller()
	{
		//phaseCut.ZeroCrossEvent();
	}
Und dann hab ich jeweils
- den attachInterrupt raus genommen => Funkt
- attachInterrupt rein, direkt danach ein detachInterrupt => FAIL
- nur ein detachInterrupt => FAIL

Hier der Sketch:

Code: Alles auswählen

#define EI_NOTEXTERNAL
#include <EnableInterrupt.h>
#include <AskSinPP.h>
#include <Dimmer.h>

//Dont debug for debugging purposes
//#define NDEBUG

#define LED_PIN 4
#define CONFIG_BUTTON_PIN 8
#define ZEROPIN 3
#define DIMMER1_PIN 5 //Dimm Triac

#define PEERS_PER_CHANNEL 4
#define PHASECUT_MODE 0 // 0 = trailing-edge phase cut; 1 = leading-edge phase cut

using namespace as;

const struct DeviceInfo PROGMEM devinfo = {
    {0x11,0x12,0x22},       // Device ID
    "papa111222",           // Device Serial
    {0x00,0x67},            // Device Model
    0x25,                   // Firmware Version
    as::DeviceType::Dimmer, // Device Type
    {0x01,0x00}             // Info Bytes
};


typedef AvrSPI<10,11,12,13> SPIType;
typedef Radio<SPIType,2> RadioType;
typedef StatusLed<LED_PIN> LedType;
typedef AskSin<LedType,NoBattery,RadioType> HalType;
typedef DimmerChannel<HalType,PEERS_PER_CHANNEL> ChannelType;
typedef DimmerDevice<HalType,ChannelType,3,3> DimmerType;

HalType hal;
DimmerType sdev(devinfo,0x20);
DimmerControl<HalType,DimmerType,ZC_Control<>> control(sdev);
ConfigToggleButton<DimmerType> cfgBtn(sdev);

void setup () {
  DINIT(57600,ASKSIN_PLUS_PLUS_IDENTIFIER);
  
  if( control.init(hal,DIMMER1_PIN) ) {
    // first init - setup connection between button and first channel
    sdev.channel(1).peer(cfgBtn.peer());
  }
  buttonISR(cfgBtn,CONFIG_BUTTON_PIN);

  sdev.initDone();
  //DDEVINFO(sdev);
}

void loop() {
  //hal.runready();
  //sdev.pollRadio();
  bool worked = hal.runready();
  bool poll = sdev.pollRadio();
  if( worked == false && poll == false ) {
    //hal.activity.savePower<Idle<true> >(hal);
  }
}

Hier noch der Output auf der Seriellen:

Wenns nicht funktioniert:

Code: Alles auswählen

AskSin++ V4.1.7 (Dec 10 2020 16:30:44)
Address Space: 32 - 843
CC init1
CC Version: 04
 - ready
Config Freq: 0x2165AA
<- 0F 01 86 10 111222 000000 06 01 00 00 00 00  - 4235
<- 0F 02 86 10 111222 000000 06 02 00 00 00 00  - 4335
<- 0F 03 86 10 111222 000000 06 03 00 00 00 00  - 4435
 debounce
 pressed
 longpressed
 longreleased
<- 1A 04 84 00 111222 000000 25 00 67 70 61 70 61 31 31 31 32 32 32 20 03 01 00  - 16156
Wenn funktioniert

Code: Alles auswählen

AskSin++ V4.1.7 (Dec 10 2020 16:27:18)
Address Space: 32 - 843
CC init1
CC Version: 04
 - ready
Config Freq: 0x2165AA
<- 0F 01 86 10 111222 000000 06 01 00 00 00 00  - 4235
<- 0F 02 86 10 111222 000000 06 02 00 00 00 00  - 4335
<- 0F 03 86 10 111222 000000 06 03 00 00 00 00  - 4435
ignore 27 10 00 8E 2696DA B9398B 00 00 18 19 41 4E E9 96 DF 8E 83 E9 5C F9 24 CE DA 2A 02 A5 21 1D 5B 5F DC 8E 2E F5 A4 3B  - 45131
 debounce
 pressed
 longpressed
 longreleased
<- 1A 04 84 00 111222 000000 25 00 67 70 61 70 61 31 31 31 32 32 32 20 03 01 00  - 117821

-> 10 01 A0 01 FFDB6B 111222 00 05 00 00 00 00 00  - 118013
<- 0A 01 80 02 111222 FFDB6B 00  - 118130
-> 13 0A A0 01 FFDB6B 111222 00 08 02 81 0A FF 0B DB 0C 6B  - 118171
<- 0A 0A 80 02 111222 FFDB6B 00  - 118290
-> 0B 13 A0 01 FFDB6B 111222 00 06  - 118323
<- 0A 13 82 02 111222 FFDB6B 00  - 118441
-> 10 1C A0 01 FFDB6B 111222 00 04 00 00 00 00 00  - 118480
<- 14 1C 80 10 111222 FFDB6B 02 02 81 0A FF 0B DB 0C 6B 00 00  - 118611
-> 10 25 A0 01 FFDB6B 111222 01 04 00 00 00 00 01  - 118648
<- 1A 25 A0 10 111222 FFDB6B 02 08 00 30 06 32 50 34 4B 35 50 56 00 57 24 58 01  - 118788
-> 0A 25 80 02 FFDB6B 111222 00  - 118902
waitAck: 01
<- 0E 25 80 10 111222 FFDB6B 02 59 01 00 00  - 118937
-> 0B 2E A0 01 FFDB6B 111222 01 03  - 118970
<- 12 2E 80 10 111222 FFDB6B 01 21 22 01 00 00 00 00 00  - 119099
-> 10 37 A0 01 FFDB6B 111222 01 04 21 22 01 00 03  - 119136
<- 1A 37 A0 10 111222 FFDB6B 02 01 00 02 00 03 32 04 64 05 00 06 FF 07 00 08 FF  - 119277
-> 0A 37 80 02 FFDB6B 111222 00  - 119392
waitAck: 01
<- 1A 37 A0 10 111222 FFDB6B 02 09 01 0A 14 0B 52 0C 63 0D 20 0E 00 0F 02 10 C8  - 119437
-> 0A 37 80 02 FFDB6B 111222 00  - 119554
waitAck: 01
<- 1A 37 A0 10 111222 FFDB6B 02 11 0A 12 0A 13 0A 14 0A 15 C8 16 05 17 0A 18 05  - 119599
-> 0A 37 80 02 FFDB6B 111222 00  - 119715
waitAck: 01
<- 1A 37 A0 10 111222 FFDB6B 02 19 05 1A 00 26 11 27 11 28 11 29 00 81 00 82 00  - 119760
-> 0A 37 80 02 FFDB6B 111222 00  - 119877
waitAck: 01
<- 1A 37 A0 10 111222 FFDB6B 02 83 32 84 64 85 00 86 FF 87 00 88 FF 89 27 8A 00  - 119922
-> 0A 37 80 02 FFDB6B 111222 00  - 120039
waitAck: 01
<- 1A 37 A0 10 111222 FFDB6B 02 8B 00 8C 00 8D 20 8E 00 8F 02 90 C8 91 0A 92 0A  - 120084
-> 0A 37 80 02 FFDB6B 111222 00  - 120199
waitAck: 01
<- 1A 37 A0 10 111222 FFDB6B 02 93 0A 94 0A 95 C8 96 05 97 0A 98 05 99 05 9A 00  - 120246
-> 0A 37 80 02 FFDB6B 111222 00  - 120360
waitAck: 01
<- 14 37 80 10 111222 FFDB6B 02 A6 11 A7 11 A8 11 A9 00 00 00  - 120401
-> 10 40 A0 01 FFDB6B 111222 02 04 00 00 00 00 01  - 120438
<- 1A 40 A0 10 111222 FFDB6B 02 08 00 30 06 32 50 34 4B 35 50 56 00 57 24 58 01  - 120578
-> 0A 40 80 02 FFDB6B 111222 00  - 120692
waitAck: 01
<- 0E 40 80 10 111222 FFDB6B 02 59 00 00 00  - 120727
-> 0B 49 A0 01 FFDB6B 111222 02 03  - 120758
<- 0E 49 80 10 111222 FFDB6B 01 00 00 00 00  - 120885
-> 10 52 A0 01 FFDB6B 111222 03 04 00 00 00 00 01  - 120922
<- 1A 52 A0 10 111222 FFDB6B 02 08 00 30 06 32 50 34 4B 35 50 56 00 57 24 58 01  - 121057
-> 0A 52 80 02 FFDB6B 111222 00  - 121174
waitAck: 01
<- 0E 52 80 10 111222 FFDB6B 02 59 00 00 00  - 121206
-> 0B 5B A0 01 FFDB6B 111222 03 03  - 121239
<- 0E 5B 80 10 111222 FFDB6B 01 00 00 00 00  - 121366
-> 10 64 A0 01 FFDB6B 111222 00 05 00 00 00 00 00  - 128555
<- 0A 64 80 02 111222 FFDB6B 00  - 128671
-> 13 6D A0 01 FFDB6B 111222 00 08 02 00 0A 00 0B 00 0C 00  - 128710
<- 0A 6D 80 02 111222 FFDB6B 00  - 128831
-> 0B 76 A0 01 FFDB6B 111222 00 06  - 128862
<- 0A 76 82 02 111222 FFDB6B 00  - 128980


Falls gewünscht kann ich noch die HW Schematik etc. posten, aber ich glaub nicht, dass es ein HW Problem ist...

Und jetzt hoff ich, dass ich nicht irgendeinen Blödsinn übersehen hab :)

jp112sdl
Beiträge: 12115
Registriert: 20.11.2016, 20:01
Hat sich bedankt: 848 Mal
Danksagung erhalten: 2150 Mal
Kontaktdaten:

Re: Status von PhaseCut Dimmer

Beitrag von jp112sdl » 10.12.2020, 19:42

Ohne es zu testen, der Fehler ist offensichtlich :mrgreen:

Dein #define ZEROPIN 3 erfolgt nach den #includes

Das heißt, zum Zeitpunkt der Einbindung der PhaseCut ist dein Define noch nicht gesetzt und es wird der #define aus der PhaseCut.h geladen
https://github.com/pa-pa/AskSinPP/blob/ ... .h#L14-L16

Und das ist Pin 2 wo auch der GDO0 vom CC1101 dran hängt.

:arrow: schreib das #define ZEROPIN 3 nach ganz oben in den Sketch und alles ist gut

Im Beispiel-Sketch ist es genau so falsch, nur fällt es nicht auf weil beim 644 der Pin 2 ohnehin als ZEROPIN genommen wird

VG,
Jérôme ☕️

---
Support for my Homebrew-Devices: Download JP-HB-Devices Addon

TomMajor
Beiträge: 1793
Registriert: 30.08.2017, 23:25
Hat sich bedankt: 175 Mal
Danksagung erhalten: 399 Mal
Kontaktdaten:

Re: Status von PhaseCut Dimmer

Beitrag von TomMajor » 10.12.2020, 23:12

Gute Beobachtung Jerome und passt perfekt zum Fehlerbild.
Eventuell wäre es sauberer das define des Zeropins komplett aus der Library rauszulassen und dies dem user zu überlassen (so wie in vielen Examples Pins für LED, Taster usw. user-defined sind), wenn er es nicht tut kommt ein Fehler.
Viele Grüße,
Tom

jp112sdl
Beiträge: 12115
Registriert: 20.11.2016, 20:01
Hat sich bedankt: 848 Mal
Danksagung erhalten: 2150 Mal
Kontaktdaten:

Re: Status von PhaseCut Dimmer

Beitrag von jp112sdl » 11.12.2020, 07:13

TomMajor hat geschrieben:
10.12.2020, 23:12
Eventuell wäre es sauberer das define des Zeropins komplett aus der Library rauszulassen und dies dem user zu überlassen
Das Blöde ist, dass die .cpp immer mitkompiliert wird, auch wenn man sie im Projekt gar nicht verwendet.
Zumindest unter den Default-Compiler-Settings der Arduino IDE. Keine Ahnung, ob man das mit irgendwelchen Schaltern verhindern kann.
Und zum Kompilieren müssen halt die Variablen vorbelegt werden.

Aber könnte man nicht den ganzen Kram aus .cpp mit in die .h packen, wie bei fast allen anderen AskSinPP-Lib-Files auch?

VG,
Jérôme ☕️

---
Support for my Homebrew-Devices: Download JP-HB-Devices Addon

fry
Beiträge: 11
Registriert: 08.12.2020, 10:39
System: CCU

Re: Status von PhaseCut Dimmer

Beitrag von fry » 11.12.2020, 07:51

Also erstmals vielen Dank für die Hilfe!

War ja klar, dass ich da irgendwas offensichtliches verpass :)

Ich hab mal den ZEROPIN vor das include gesetzt.
Irgendwie hat er das nicht übernommen, um mal weiter zu kommen hab ich den Pin hardcoded ins cpp geschrieben.

Kann mir das später ansehen, aktuell hab ich zwei andere Aspekte am start:

- Meine ZC Schaltung ist in Wirklichkeit eine peak-detect Schaltung.
Also muss ich entweder die Schaltung ändern oder den code.
Könnt Ihr mir sagen in welchem Bereich sich der DimValue bewegt?
Ist das 0-100?
Check noch nicht ganz, warum er ein mal den Timer auf den DimValue setzt und dann nur noch <75 referenziert.

- Es gibt offenbar keine Umrechnung in effektive Leistung
Wenn ich an der Sinuswelle rumschneid entspricht die on-time in % ja nicht der Leistung in %.
Es gibt eine Arduino Dimmer Library in der sie das als Tabelle rein genommen haben.
Vielleicht spiel ich mich damit auch noch mal, aber zuerst möcht ich die Welle richtig schneiden...
Quelle

Falls es Euch interessiert kann ich gerne Screenshots vom Oszi posten.

Bin für Tipps wie Ihr die ZC vs. Peak detect lösen würdet dankbar, ev kann mir Jmd erklären wie der Dim Wert aussieht und warum die 75 als Referenz ausreicht?

Danke & LG!

jp112sdl
Beiträge: 12115
Registriert: 20.11.2016, 20:01
Hat sich bedankt: 848 Mal
Danksagung erhalten: 2150 Mal
Kontaktdaten:

Re: Status von PhaseCut Dimmer

Beitrag von jp112sdl » 11.12.2020, 08:24

fry hat geschrieben:
11.12.2020, 07:51
Könnt Ihr mir sagen in welchem Bereich sich der DimValue bewegt?
Also wenn das direkt der LEVEL-Wert von der CCU ist, dann geht es von 0 - 200

Ansonsten bin ich beim Thema "Dimmer" komplett raus. Da kann ich technisch 0,nix beitragen

VG,
Jérôme ☕️

---
Support for my Homebrew-Devices: Download JP-HB-Devices Addon

fry
Beiträge: 11
Registriert: 08.12.2020, 10:39
System: CCU

Re: Status von PhaseCut Dimmer

Beitrag von fry » 11.12.2020, 10:06

kein prob, hat mir schon sehr geholfen!

Langsam check ich den Code und hab auch schon rausgefunden, dass die Korrektur-Table im PWM.h steht und der somit angewandte Dim Wert zwischen o und 75 ist...

Wenn ich zu einem sinnvollen Ergebnis komm meld ich mich wieder!

Antworten

Zurück zu „Hardwareentwicklung und Selbstbau von Aktoren und Sensoren“