HM/AskSinPP: Abschaltung CC1101
Moderator: Co-Administratoren
-
- Beiträge: 12108
- Registriert: 20.11.2016, 20:01
- Hat sich bedankt: 848 Mal
- Danksagung erhalten: 2148 Mal
- Kontaktdaten:
HM/AskSinPP: Abschaltung CC1101
Ich versuche gerade zu verstehen, wie (bzw. warum) eQ-3 die (Ab)schaltung des Funkmoduls in einigen Geräten so gebaut hat:
Ich habe die Schaltung nachgebaut und auf D2 und R10 verzichtet.
Das hat zur Folge, dass nach dem Aufwecken des AVR die Initialisierung des CC1101 scheitert.
Der ganze AVR hängt sich komplett auf - ich sehe nur noch die LED_BUILTIN (Pin 13 / SCK) schwach leuchten.
(Seltsamerweise nur dann, wenn sich die Schaltung eine Weile (einige Minuten) im Powerdown/"SLEEP_FOREVER" befand und dann geweckt wird. Warte ich nur einige Sekunden nach dem Sleep, dann klappt das Wakeup zuverlässig.
Mir ist völlig rätselhaft, welche Rolle die Zeit dabei spielt. Vielleicht entlädt sich da noch was im Hintergrund allmählich?)
Mit D2 und R10 klappt die Initialisierung auch nach längerem Sleep zuverlässig.
Habe jedoch nicht weiter getestet, ob evtl. nur eines der beiden Bauteile schon ausreichend wäre.
Nun frag ich mich, welche Rolle D2 (und R10) dabei spielen.
Speziell interessiert mich die Funktion der Schottky-Diode D2 in der CS-Leitung.Ich habe die Schaltung nachgebaut und auf D2 und R10 verzichtet.
Das hat zur Folge, dass nach dem Aufwecken des AVR die Initialisierung des CC1101 scheitert.
Der ganze AVR hängt sich komplett auf - ich sehe nur noch die LED_BUILTIN (Pin 13 / SCK) schwach leuchten.
(Seltsamerweise nur dann, wenn sich die Schaltung eine Weile (einige Minuten) im Powerdown/"SLEEP_FOREVER" befand und dann geweckt wird. Warte ich nur einige Sekunden nach dem Sleep, dann klappt das Wakeup zuverlässig.
Mir ist völlig rätselhaft, welche Rolle die Zeit dabei spielt. Vielleicht entlädt sich da noch was im Hintergrund allmählich?)
Mit D2 und R10 klappt die Initialisierung auch nach längerem Sleep zuverlässig.
Habe jedoch nicht weiter getestet, ob evtl. nur eines der beiden Bauteile schon ausreichend wäre.
Nun frag ich mich, welche Rolle D2 (und R10) dabei spielen.
-
- Beiträge: 5422
- Registriert: 30.05.2019, 11:37
- System: Alternative CCU (auf Basis OCCU)
- Wohnort: Chemnitz
- Hat sich bedankt: 114 Mal
- Danksagung erhalten: 733 Mal
Re: HM/AskSinPP: Abschaltung CC1101
Na ja, ohne D2 würde der Controller bei /CS = high ja sonst Strom einspeisen über /CS in das spannungslose TRX-Modul. Wer weiß, was da die Folge ist (außer erhöhte Stromaufnahme). Und Schottky, um den Low-Pegel einzuhalten.
Da durch die Diode kein sicherer High-Pegel mehr möglich ist, wird dieser wohl per R10 sichergestellt.
Da durch die Diode kein sicherer High-Pegel mehr möglich ist, wird dieser wohl per R10 sichergestellt.
-
- Beiträge: 1793
- Registriert: 30.08.2017, 23:25
- Hat sich bedankt: 175 Mal
- Danksagung erhalten: 399 Mal
- Kontaktdaten:
Re: HM/AskSinPP: Abschaltung CC1101
Der Gedanke kam auch schon mal auf als Jerome und ich uns früher darüber austauschten.Matsch hat geschrieben: ↑09.08.2021, 23:24Na ja, ohne D2 würde der Controller bei /CS = high ja sonst Strom einspeisen über /CS in das spannungslose TRX-Modul. Wer weiß, was da die Folge ist (außer erhöhte Stromaufnahme). Und Schottky, um den Low-Pegel einzuhalten.
Da durch die Diode kein sicherer High-Pegel mehr möglich ist, wird dieser wohl per R10 sichergestellt.
Das Argument mit dem Strom einspeisen gilt aber genau so für MISO, MOSI und SCK, oder?
Sauberes Design bzgl. Einspeisung wäre alle Leitungen zum TRX auf Low oder hochohmig zu setzten wenn TRX abgeschaltet wird.
Und wenn sie dies für MISO, MOSI und SCK tun können, warum dann nicht auch für /CS ohne extra HW?
Viele Grüße,
Tom
Tom
-
- Beiträge: 12108
- Registriert: 20.11.2016, 20:01
- Hat sich bedankt: 848 Mal
- Danksagung erhalten: 2148 Mal
- Kontaktdaten:
Re: HM/AskSinPP: Abschaltung CC1101
Im abgeschalteten Zustand werden >>>alle 3 SPI Pins als Eingang<<< konfiguriert.
Soweit ich es debuggen konnte, bleib er im Fehlerfall >>>hier<<< in der while-Schleife hängen.
Ein großzügiges Delay zwischen dem Konfigurieren der Pins (init()) und dem Senden der Initialisierungs-Register an das CC1101 ändert rein gar nichts.
Die Erklärung scheint also gar nicht so trivial zu sein...
Aber die eine Diode nimmt im PCB Design jetzt auch nicht wahnsinnig viel Platz weg.
Soweit ich es debuggen konnte, bleib er im Fehlerfall >>>hier<<< in der while-Schleife hängen.
Ein großzügiges Delay zwischen dem Konfigurieren der Pins (init()) und dem Senden der Initialisierungs-Register an das CC1101 ändert rein gar nichts.
Die Erklärung scheint also gar nicht so trivial zu sein...
Aber die eine Diode nimmt im PCB Design jetzt auch nicht wahnsinnig viel Platz weg.
- stan23
- Beiträge: 2038
- Registriert: 13.12.2016, 21:14
- System: Alternative CCU (auf Basis OCCU)
- Wohnort: Altmühltal
- Hat sich bedankt: 582 Mal
- Danksagung erhalten: 336 Mal
- Kontaktdaten:
Re: HM/AskSinPP: Abschaltung CC1101
Der Pull-up ist meiner Meinung nach drin, weil ein low Pegel auf CSn das Funkmodul aufweckt.
Um das zu verhindern während der ATmega vielleicht unpässlich ist, ist der Pull-up da.
Um das zu verhindern während der ATmega vielleicht unpässlich ist, ist der Pull-up da.
Viele Grüße
Marco
RaspberryMatic als VM auf einem NUC mit Proxmox und USB-Funkmodul
~80 Geräte (HM, HmIP, HMW, HBW, AskSin)
Marco
RaspberryMatic als VM auf einem NUC mit Proxmox und USB-Funkmodul
~80 Geräte (HM, HmIP, HMW, HBW, AskSin)
-
- Beiträge: 75
- Registriert: 04.02.2019, 10:04
- Hat sich bedankt: 15 Mal
- Danksagung erhalten: 9 Mal
Re: HM/AskSinPP: Abschaltung CC1101
Hallo zusammen,
ich denke, es hängt damit zusammen: Ich würde mal testweise einen anderen Pin als CS nehmen, oder ihn nur low schalten, statt auf Input um das zu testen/bestätigen..
Würde auch die Zeitabhängigkeit erklären, wenn der Puffer Kondensator leer ist, wird der Port low gezogen, vorher noch nicht.
Mit Diode bleibt er vermutlich über den internen PullUp high.
ich denke, es hängt damit zusammen: Ich würde mal testweise einen anderen Pin als CS nehmen, oder ihn nur low schalten, statt auf Input um das zu testen/bestätigen..
Würde auch die Zeitabhängigkeit erklären, wenn der Puffer Kondensator leer ist, wird der Port low gezogen, vorher noch nicht.
Mit Diode bleibt er vermutlich über den internen PullUp high.
Gruß, Dirk
System:
Selbst entwickelte Wandmodule (15Stk/eins pro Raum) mit 3*Rollo, 3*Relais, 3*Dimmer, 9*Tastereingängen, 4*4 Matrix für Tür-/Fenster Kontakte (auf/zu/kipp) im 2005 gebauten Einfamilienhaus, verbunden über CAN Bus, lokale Tabellen für Aktionen, 1* - 5* Tastendruck (üblich 1x 4-fach Taster verbaut) und Änderung Kontaktstatus, parametrierbar über eigene Windows Software, aktuell gesteuert über selbst gebautes CAN - Ethernet Interface und OpenHAB per HTTP Binding (JSON/GET/POST).
Zusätzlich diverse Xiaomi Sensoren (Temperatur und Brandmelder) und Homematic/AskSinPP Komponenten (über Homegear) für "vergessene" Funktionen...
System:
Selbst entwickelte Wandmodule (15Stk/eins pro Raum) mit 3*Rollo, 3*Relais, 3*Dimmer, 9*Tastereingängen, 4*4 Matrix für Tür-/Fenster Kontakte (auf/zu/kipp) im 2005 gebauten Einfamilienhaus, verbunden über CAN Bus, lokale Tabellen für Aktionen, 1* - 5* Tastendruck (üblich 1x 4-fach Taster verbaut) und Änderung Kontaktstatus, parametrierbar über eigene Windows Software, aktuell gesteuert über selbst gebautes CAN - Ethernet Interface und OpenHAB per HTTP Binding (JSON/GET/POST).
Zusätzlich diverse Xiaomi Sensoren (Temperatur und Brandmelder) und Homematic/AskSinPP Komponenten (über Homegear) für "vergessene" Funktionen...
- stan23
- Beiträge: 2038
- Registriert: 13.12.2016, 21:14
- System: Alternative CCU (auf Basis OCCU)
- Wohnort: Altmühltal
- Hat sich bedankt: 582 Mal
- Danksagung erhalten: 336 Mal
- Kontaktdaten:
Re: HM/AskSinPP: Abschaltung CC1101
Da ist doch außer dem CC1101 gar kein anderer Teilnehmer am SPI, also ist es kein Multi Slave System.
Oder soll das zur Robustheit beim ISP-Flashen in der Fab helfen, um den CC1101 im Sleep zu halten während der ATmega programmiert wird? Denn da wird ja eigentlich die Spec des CC1101 verletzt:
Oder soll das zur Robustheit beim ISP-Flashen in der Fab helfen, um den CC1101 im Sleep zu halten während der ATmega programmiert wird? Denn da wird ja eigentlich die Spec des CC1101 verletzt:
Voltage on any digital pin: MAX VDD + 0.3 V
Viele Grüße
Marco
RaspberryMatic als VM auf einem NUC mit Proxmox und USB-Funkmodul
~80 Geräte (HM, HmIP, HMW, HBW, AskSin)
Marco
RaspberryMatic als VM auf einem NUC mit Proxmox und USB-Funkmodul
~80 Geräte (HM, HmIP, HMW, HBW, AskSin)
-
- Beiträge: 75
- Registriert: 04.02.2019, 10:04
- Hat sich bedankt: 15 Mal
- Danksagung erhalten: 9 Mal
Re: HM/AskSinPP: Abschaltung CC1101
Es geht nicht um Multimaster, sondern die Tatsache, dass, wenn man SS auf Eingang schaltet, die SPI Hardware in den Slave Mode wechselt, wenn der SS Pin low wird.
Mit dem Programmieren hat das wohl wenig zu tun, das würde ja ebenfalls für die restlichen Signale des SPI Busses gelten.
Mit dem Programmieren hat das wohl wenig zu tun, das würde ja ebenfalls für die restlichen Signale des SPI Busses gelten.
Gruß, Dirk
System:
Selbst entwickelte Wandmodule (15Stk/eins pro Raum) mit 3*Rollo, 3*Relais, 3*Dimmer, 9*Tastereingängen, 4*4 Matrix für Tür-/Fenster Kontakte (auf/zu/kipp) im 2005 gebauten Einfamilienhaus, verbunden über CAN Bus, lokale Tabellen für Aktionen, 1* - 5* Tastendruck (üblich 1x 4-fach Taster verbaut) und Änderung Kontaktstatus, parametrierbar über eigene Windows Software, aktuell gesteuert über selbst gebautes CAN - Ethernet Interface und OpenHAB per HTTP Binding (JSON/GET/POST).
Zusätzlich diverse Xiaomi Sensoren (Temperatur und Brandmelder) und Homematic/AskSinPP Komponenten (über Homegear) für "vergessene" Funktionen...
System:
Selbst entwickelte Wandmodule (15Stk/eins pro Raum) mit 3*Rollo, 3*Relais, 3*Dimmer, 9*Tastereingängen, 4*4 Matrix für Tür-/Fenster Kontakte (auf/zu/kipp) im 2005 gebauten Einfamilienhaus, verbunden über CAN Bus, lokale Tabellen für Aktionen, 1* - 5* Tastendruck (üblich 1x 4-fach Taster verbaut) und Änderung Kontaktstatus, parametrierbar über eigene Windows Software, aktuell gesteuert über selbst gebautes CAN - Ethernet Interface und OpenHAB per HTTP Binding (JSON/GET/POST).
Zusätzlich diverse Xiaomi Sensoren (Temperatur und Brandmelder) und Homematic/AskSinPP Komponenten (über Homegear) für "vergessene" Funktionen...
-
- Beiträge: 1793
- Registriert: 30.08.2017, 23:25
- Hat sich bedankt: 175 Mal
- Danksagung erhalten: 399 Mal
- Kontaktdaten:
Re: HM/AskSinPP: Abschaltung CC1101
die Slave Mode Sache ist aber wirklich nur für den Fall dass /SS per SW auf input gesetzt wird. Ist m.E. ein eher seltener Anwendungsfall in einem simplen und fest definiertem Master-Slave System.
Nur für die TRX-Modul Abschaltung könnte man auf diese Idee kommen um High-Z Zustand zu erreichen. Dann sollte man aber besser imho die SPI ganz abschalten und alle Pins auf Low oder High-Z.
@Jerome
Bei meinen Untersuchen für papa
viewtopic.php?f=76&t=66483&p=662272#p652605
hatte ich kein D/R und hat trotzdem funktioniert (nachdem das Problem klar wurde), habe aber keine umfangreichen Tests bzgl. verschiedener sleep Zeiten gemacht.
Versuch mal die beiden Spannungen Vcc und VTrx mit Oszi zu beobachten für verschiedene Fälle der sleep Zeiten sowie für den D/R Fall, vllt. ergeben sich interessante Unterschiede.
Nur für die TRX-Modul Abschaltung könnte man auf diese Idee kommen um High-Z Zustand zu erreichen. Dann sollte man aber besser imho die SPI ganz abschalten und alle Pins auf Low oder High-Z.
@Jerome
Bei meinen Untersuchen für papa
viewtopic.php?f=76&t=66483&p=662272#p652605
hatte ich kein D/R und hat trotzdem funktioniert (nachdem das Problem klar wurde), habe aber keine umfangreichen Tests bzgl. verschiedener sleep Zeiten gemacht.
Versuch mal die beiden Spannungen Vcc und VTrx mit Oszi zu beobachten für verschiedene Fälle der sleep Zeiten sowie für den D/R Fall, vllt. ergeben sich interessante Unterschiede.
Viele Grüße,
Tom
Tom
-
- Beiträge: 12108
- Registriert: 20.11.2016, 20:01
- Hat sich bedankt: 848 Mal
- Danksagung erhalten: 2148 Mal
- Kontaktdaten:
Re: HM/AskSinPP: Abschaltung CC1101
Das ist echt kurios. Ohne D/R kommt keine meiner Aufbauten wieder ins Leben zurück
Aber wie es aussieht, reicht der Pullup-R am CS aus.
Hab die Diode grad mal überbrückt und es geht immer noch.
Ich werd die Diode in der PCB dennoch vorsehen. Kann man ja problemlos überbrücken