Forum: Projekte & Code Ultra Low Power LED Flasher mit Padauk PFS154


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Tim  . (cpldcpu)


Angehängte Dateien:

Lesenswert?

Angeregt von einem anderen Diskussionsthread 
(Beitrag "selbstblinkende SMD-LED mit niedrigem Stromverbrauch") habe ich mich damit 
beschäftigt, einen LED flasher mit der "3-cent MCU" zu entwickeln.

Die Problemstellung, eine LED möglichst lange mit Hilfe einer einzelnen 
Batterie blinken oder leuchten zu lassen, wurde schon an vielen anderen 
Stellen untersucht:

z.B. der "Ewige Blinker" von Burkhard Kainka: 
http://www.b-kainka.de/bastel59.htm

Oder die TritiLED von Ted Yapo: 
https://hackaday.io/project/11864-tritiled

Es zeigt sich relativ schnell, dass das Hauptproblem darin besteht einen 
Timer mit sehr geringem active-Stromverbrauch zu bauen, der dann einen 
Strompuls in der LED auslöst. Lösungen mit diskreten Bauteilen stoßen 
relativ schnell an Grenzen, da man hier sehr hohe Widerstände für das 
Biasing benötigt, die sich nicht mit vorhandenen parasitäten Kapazitäten 
vertragen. (z.B. 
https://hackaday.io/project/11864-tritiled/log/114986-dude-wheres-my-mcu 
oder http://www.discovercircuits.com/DJ-Circuits/astable.htm).

Auf einem IC integrierte Oszillatoren müssen mit deutlich weniger 
parasitären Kapazitäten umgehen und können daher Energieeffizienter 
sein. Wie man an der Tritiled sieht ist, ist es durchaus effizient hier 
einen low-power Microcontroller zu nutzen.

Trotz des geringen Preises haben die Padauk-MCUs erstaunlich gute low 
power Eigenschaften, die zumindest vom Datenblatt her mit viele anderen 
8Bittern mithalten können.

Die Bilder im Anhang zeigen meine Lösung. Die MCU lässt eine an PA4 
angeschlossene grüne LED mit einer Frequenz von 1.6 Hz für 75µs 
aufblitzen. Dieses ist gut sichtbar.

Der durchschnittliche Stromverbrauch beträgt dabei je nach 
Betriebsspannung zwischen 0.6 µA und 2.3 µA! (Zum Vergleich: Der "ewige 
Blinker" benötigt 50µA)

Messergebnisse und Modellrechnungen im Plot anbei. Ebenso der 
Sourcecode. Ich war etwas überrascht, die kleinen Ströme überhaupt mit 
meinem einfachen Handmessgerät bestimmen zu können. Dazu habe ich einen 
330µF Elko zu Glättung eingesetzt. Meine Messergebnisse stimmen ungefähr 
mit dem Padauk Datenblatt und meinen Modellierungen überein. Daher gehe 
ich davon aus, dass der Fehler nicht sehr groß ist.

Der Flasher lässt sich an einem auf 5V aufgeladenen 330µF Elko für ca 13 
Minuten betreiben.

: Bearbeitet durch User
von Tim  . (cpldcpu)


Lesenswert?

Die Umsetzung ist einigermaßen im Code dokumentiert. Ich nutze den low 
frequency oszillator als Taktquelle für die CPU. Die CPU wird per 
"STOPEXE" schlafen gelegt und mit dem Timer2 wieder aufgeweckt. In der 
Hauptschleife wird der I/O Pin PA4 für vier Taktzyklen aktiviert und 
danach die CPU wieder schlafen gelegt.

Ich nutzte den I/O Pin direkt ohne Vorwiderstand als Hi-side Treiber für 
die LED. Die I/Os sind dabei auf "low driving strength" konfiguriert, so 
dass sie den Treiberstrom auf wenige mA begrenzen. Es handelt sich um 
eine handelsübliche grüne 3mm LED. Grün, da diese Wellenlänge am besten 
sichtbar ist. Die LED leuchtet bereits ab knapp über 2V 
Vorwärtsspannung.

Der Ansatz ist relativ straightforward, aber es gab dank 
Dokumentationslücken schon ein paar Fallstricke. Werde ich evtl. noch 
einmal im Detail aufschreiben.

Es gibt noch viele Möglichkeiten, Dinge zu verbessern. z.B. könnte man 
die LED mit einem Boost-Converter (TritiLED) oder einer Ladungspumpe 
(ewiger Blinker) betreiben, um die LED-Spannung bei niedrigem Supply zu 
erhöhen.

Alternativ könnte man weitere Funktionen in der MCU unterbringen und 
z.B. die Betriebsspannung messen, um abhängig davon die Ansteuerung der 
LED anzupassen.
1
unsigned char _sdcc_external_startup(void)
2
{
3
  PDK_SET_FUSE(FUSE_IO_DRV_LOW);  // Set output driving strength to low
4
  
5
  CLKMD =  CLKMD_ILRC | CLKMD_ENABLE_ILRC | CLKMD_ENABLE_IHRC; 
6
  CLKMD =  CLKMD_ILRC | CLKMD_ENABLE_ILRC ; 
7
8
    // Note: it is important to turn off IHRC only after clock settings
9
    // have been updated. Otherwise the CPU stalls.
10
  return 0; // perform normal initialization
11
}
12
13
void main(void)
14
{
15
  // Stopsys with 5V: 0.5 µA
16
  // The watchdog cannot wake up from stopexe!!
17
18
  PADIER = 0; // disable pins as wakeup source
19
  PBDIER = 0; // Also port B needs to be disabled even if it is not connected
20
        // to the outside of the package. touching the package can introduce 
21
        // glitches and wake up the device
22
23
  INTEN = 0;  // Make sure all interrupts are disabled
24
  INTRQ = 0;
25
26
  MISC = MISC_FAST_WAKEUP_ENABLE;  // Enable faster wakeup (45 clocks instead of 3000)
27
                   // This is important to not waste energy, as 40µA bias is already added during wakeup time
28
29
  // Configure timer two for output on PA3
30
  // --> Works, timer2 and 2 can be used for PWM while CPU is in STOPEXE mode
31
  // It appears that also timer 2 can wake up the CPU. This is not maskable?
32
33
  TM2C  = TM2C_CLK_ILRC | TM2C_MODE_PWM;  // Oscilator source for timer 2 is LRC (53 kHZ)
34
  TM2CT = 0;
35
  TM2S  = TM2S_PRESCALE_DIV16 | TM2S_SCALE_DIV8; // Divide clock by 16*7=112 -> 53 kHz / 122 = 414 Hz    
36
  TM2B  = 1;  // PWM threshold set to 1. The PWM event will trigger the wakeup. Wakeup occurs with 414 Hz / 256 = 1.66 Hz
37
38
  PA    = 1<<4;  // LED is on PA4, set all other output to zero.
39
  PAPH   = 0;   // Disable all pull up resistors
40
  PAC    = 0;     // Disable all outputs
41
           // Note: There is no series resistor for the LED
42
           // The LED current is limited to 2-4 mA by LOW IO driving setting
43
           // See Setction 4.14 (p24) in PFS154 manual
44
           // The output is disabled when the LED is off to avoid leakage
45
46
  for (;;) {  
47
    PAC |=1<<4;  // Enable LED output (It's set to High)
48
    __nop();
49
    __nop();
50
    __nop();
51
    PAC &=~(1<<4); // Disable LED output after 4 cycles => 4/53 kHz = 75.5 µS
52
    __stopexe();
53
  }
54
}

: Bearbeitet durch User
von Harald (Gast)


Lesenswert?

Das wären ja theoretisch 20 Jahre aus einer CR2032. Wenn man mal die 
Selbstentladung mit einbezieht dürften noch 5..10 Jahre übrig bleiben.

Vllt. noch ein Hinweis auf LEDs: ich habe bisher schon einige PCB bei 
JLCPCB teilbestücken lassen, wenn man da in der Parts Library nach 
weißen LEDs in 0805 sucht, läuft einem immer die C34499 über den Weg. 
Die habe ich jetzt schon ein paar Mal verwendet und die ist wirklich 
bereits bei kleinen Strömen schon schweinehell. Das beste ist die 
Durchlassspannung, trotz Weiß ist die mit nur 1.7...2.3V spezifiziert, 
kann man ohne weiteres an 3.3V IO betreiben. Für ne CR2032 sollte es 
auch reichen.

von MaWin (Gast)


Lesenswert?

Harald schrieb:
> C34499

LCSC sagt Discontinued, Hubei Kento sagt This product is no longer 
available, und ein Datenblatt habe ich nicht gefunden.

von Tim  . (cpldcpu)


Lesenswert?

MaWin schrieb:
> LCSC sagt Discontinued, Hubei Kento sagt This product is no longer
> available, und ein Datenblatt habe ich nicht gefunden.

Das ist leider ein Thema mit JLCPCB. Die haben von einigen Bauteilen 
größere Restmengen auf Lager, mit denen man seine PCBs bestücken lassen 
kann. Gleichtzeitig ist das Produkt aber bei LCSC abgekündigt. Das 
betrifft z.B. alle LEDs von Kento. Für "ernste" Designs sollte man diese 
wahrscheinlich nicht verwenden.

von Harald (Gast)


Lesenswert?

MaWin schrieb:
> LCSC sagt Discontinued,

Ich könnte heulen, aber nun ja, das ist der Lauf der Dinge.

Datenblatt: Das ist interessant, direkt auf lcsc.com kein Datenblatt 
verlinkt, auf JLCPCB  Resources  PartsLibrary war es bis vor wenigen 
Stunden noch abrufbar. Habe doch vorhin noch die Durchlassspannung dort 
nachgesehen. JETZT ist der Link interessanterweise tot. Sehr merkwürdig.

von Harald (Gast)


Lesenswert?


von Tim  . (cpldcpu)


Lesenswert?

Harald schrieb:
> Habe es im Browserverlauf wiedergefunden
> 
https://datasheet.lcsc.com/szlcsc/Everlight-Elec-19-213-Y2C-CQ2R2L-3T-CY_C72038.pdf

Das ist allerdings eine gelbe LED. Wundert mich daher nicht, dass die 
bereits ab 1.7V leuchtet.

von MaWin (Gast)


Lesenswert?

Harald schrieb:
> Habe es im Browserverlauf wiedergefunden

Hmm, andere Grösse, andere Farbe, andere Typennummer, anderer 
Hersteller, das ist wohl nicht die gleiche.

von Harald (Gast)


Lesenswert?

Auch gerade gesehen, bin mir aber sicher, dass dieses Datenblatt bei der 
C34499 verlinkt war. Und ich bin mir auch sicher, dass die LED definitiv 
kalkweiß leuchtet. Ferner ist noch zu beobachten, dass die auf lcsc.com 
keine vernünftige Manufacturer Part Number angeben und dort auch die 
C34499 angeben.
Ich hatte noch gedacht, ob Everlight der westliche Name hinter Hubei 
Elec ist, dem ist aber nicht so.

von Harald (Gast)


Lesenswert?

Kaltweiß nicht Kalkweiß.

von Harald (Gast)


Angehängte Dateien:

Lesenswert?

So, gerade mal eine C34499 selber vermessen. Im Bild die LED bei 2,4mA, 
da hat sie 2,5V Durchlassspannung. Hat also mit dem verlinkten 
Datenblatt nichts zun tun. Hmmm.

von Harald (Gast)


Lesenswert?

Ergänzend:
250uA    2,4V
1mA     2,45V
2mA     2,5V
5mA      2,8V
10mA     2,9V

von bingo (Gast)


Lesenswert?

Ich habe hier so etwas ähnliches für den PIC12LF1822, einen 8-pinner, 
man beachte das L.

Hier lasse ich 2 LEDs kurz hintereinander für je 12 msec aufblitzen mit 
Pause 12 msec dazwischen. Dann geht der PIC in den SLEEP und braucht 0,5 
µA bei 3 V bzw 0,6 µA bei 3,6 V, bis er durch den Watchdog nach etwa 4 
sec wieder neu gestartet wird.

Ich habe den WDT verwendet, weil der weniger Strom verbraucht als der 
Timer1, der per Interrupt den SLEEP beendemn würde, und der Timer1 noch 
einen Quarz plus 2x C oder Resonator benötigt, mit dem Timer1 wäre der 
Strom knapp 1 µA.

Der Vorschlag stammt von Carl 
Beitrag "Re: selbstblinkende SMD-LED mit niedrigem Stromverbrauch"
1
; blitz_1822.asm fuer PIC12LF1822
2
; blitzt 2 LEDs und schläft dann 4 sec, wird durch WDT neu gestartet
3
4
    list p=16f1822
5
    #include <p16f1822.inc>
6
7
    ERRORLEVEL -302             ; schaltet Bank-Warnungen ab
8
9
    __CONFIG    _CONFIG1, _FOSC_INTOSC & _WDTE_ON & _PWRTE_OFF & _MCLRE_OFF & _CP_OFF & _CPD_OFF & _BOREN_OFF & _CLKOUTEN_OFF & _IESO_OFF & _FCMEN_OFF & 0x3FFF
10
    __CONFIG    _CONFIG2, _WRT_OFF & _PLLEN_OFF & _STVREN_OFF & _BORV_19 & _LVP_OFF & 0x3FFF
11
12
    cblock 0x20                 ; RAM
13
    cnt
14
    endc
15
16
#define LED0        PORTA, 0    ; LED 0
17
#define LED1        PORTA, 1    ; LED 1
18
19
bank0 macro
20
    movlb   0x00                ; Bank 0
21
    endm
22
23
bank1 macro
24
    movlb   0x01                ; Bank 1
25
    endm
26
27
bank2 macro
28
    movlb   0x02                ; Bank 2
29
    endm
30
31
bank3 macro
32
    movlb   0x03                ; Bank 3
33
    endm
34
35
bank4 macro
36
    movlb   0x04                ; Bank 4
37
    endm
38
39
    org     0x00
40
41
init
42
    bank3
43
    clrf    ANSELA              ; Port A digital
44
    bank1
45
    clrf    TRISA               ; Port A alle output
46
    bank0
47
    clrf    PORTA               ; Ports initialisieren
48
    bank2
49
    clrf    LATA                ; Ports initialisieren
50
    bank1
51
    movlw   B'00000010'         ; Oszillator 31 kHz INTOSC
52
    movwf   OSCCON
53
    clrf    INTCON              ; Interrupt disable
54
    movlw   B'00011001'         ; WDT auf 1:2^17 = 4 sec
55
    movwf   WDTCON
56
57
;***********************************************************************
58
59
    bank0
60
61
main
62
    bsf     LED0
63
    call    wait1
64
    bcf     LED0
65
    call    wait1
66
    bsf     LED1
67
    call    wait1
68
    bcf     LED1
69
70
    sleep
71
    nop                         ; nach sleep 1x nop !
72
73
    goto main
74
75
wait1
76
    movlw   0x20                ; 0x20 sind ca 12 msec bei 31 kHz
77
    movwf   cnt
78
    decfsz  cnt, f
79
    goto    $-1
80
    return
81
82
    end

von Tim  . (cpldcpu)


Lesenswert?

bingo schrieb:
> Ich habe hier so etwas ähnliches für den PIC12LF1822, einen 8-pinner,
> man beachte das L.
>
> Hier lasse ich 2 LEDs kurz hintereinander für je 12 msec aufblitzen mit
> Pause 12 msec dazwischen. Dann geht der PIC in den SLEEP und braucht 0,5
> µA bei 3 V bzw 0,6 µA bei 3,6 V, bis er durch den Watchdog nach etwa 4
> sec wieder neu gestartet wird.

Ja, so ähnlich ist das in der oben verklinkten TritiLED auch gelöst. Der 
Padauk hält den WDT allerdings zusammen mit der CPU an. Warum auch 
immer.

> Ich habe den WDT verwendet, weil der weniger Strom verbraucht als der
> Timer1, der per Interrupt den SLEEP beendemn würde, und der Timer1 noch
> einen Quarz plus 2x C oder Resonator benötigt, mit dem Timer1 wäre der
> Strom knapp 1 µA.

Der PFS154 benötigt bei 3V mit Timer 2 nach meinen Messungen 0.7µA. Und 
das ist keine Spezialversion mit "L" :). Dafür das der Preis auch noch 
eine Größenordnung kleiner ist, ist das doch nicht schlecht, oder?

: Bearbeitet durch User
von Tim  . (cpldcpu)


Angehängte Dateien:

Lesenswert?

Muss meine Strommessungen noch einmal korrigieren. Wie häufig, haben 
sich zwei Fehler gegenseitig aufgehoben.

Das Messgerät hat die durch die LED entstandenden Stromspitzen nicht 
richtig aufgelöst. Ich habe jetzt noch einmal nachgeholfen, in dem ich 
einen 4.7kOhm Widerstand in Serie geschaltet habe, um den Strom weiter 
zu glätten.

Außerdem hat sich herausgestellt, dass durch die LED teilweise doch ein 
deutlich höherer Strom floss, als es das Diagram im PFS154 Datenblatt 
vermuten ließe (Section 4.14). Evtl. sind die Testbedinungen einfach 
andere.

Ich habe noch einmal getrennt nachgemessen und jetzt passt das Modell 
auch zu den Messergebnissen.

Bei 5V fließen ca 10 mA durch die LED, was eindeutig zu hoch ist. Hier 
sind also noch Maßnahmen notwendig.

: Bearbeitet durch User
von bingo (Gast)


Lesenswert?

Tim  . schrieb:
> Der PFS154 benötigt bei 3V mit Timer 2 nach meinen Messungen 0.7µA. Und
> das ist keine Spezialversion mit "L" :). Dafür das der Preis auch noch
> eine Größenordnung kleiner ist, ist das doch nicht schlecht, oder?

Ich habe mich auch schon etwas mit den Padauks beschäftigt, 
erstaunliches P/L-Verhältnis. Ich bleibe aber lieber bei den PICs, 
zumindest vorläufig. Ich nehme bis 3,6 Volt immer die LF-Version (kostet 
praktisch gleich viel), weil die im Leerlauf deutlich weniger ziehen, 
über 3,6 Volt muss es aber der F-Typ sein.

von Tim  . (cpldcpu)


Lesenswert?

bingo schrieb:
> Tim  . schrieb:
>> Der PFS154 benötigt bei 3V mit Timer 2 nach meinen Messungen 0.7µA. Und
>> das ist keine Spezialversion mit "L" :). Dafür das der Preis auch noch
>> eine Größenordnung kleiner ist, ist das doch nicht schlecht, oder?
>
> Ich habe mich auch schon etwas mit den Padauks beschäftigt,
> erstaunliches P/L-Verhältnis. Ich bleibe aber lieber bei den PICs,
> zumindest vorläufig. Ich nehme bis 3,6 Volt immer die LF-Version (kostet
> praktisch gleich viel), weil die im Leerlauf deutlich weniger ziehen,
> über 3,6 Volt muss es aber der F-Typ sein.

Für den Preis des PIC12LF1822 bekommt man aber auch schon einen gut 
ausgerüsteten Cortex-M0 (z.B. STM32G031). Verstehe nicht ganz, warum der 
so teuer ist? (Aktuell $1.2)

von MaWin (Gast)


Lesenswert?

Tim  . schrieb:
> Es zeigt sich relativ schnell, dass das Hauptproblem darin besteht einen
> Timer mit sehr geringem active-Stromverbrauch zu bauen

Ein CD4536 braucht bei nicht zu schnellem RC Oszillator auch wenig Strom 
(wieviel realmüsste man ausprobieren) und blitzt nur kurz bei langen 
Pausen. Nur braucht er offiziell 3V.

von Tim  . (cpldcpu)


Lesenswert?

MaWin schrieb:
> Tim  . schrieb:
>> Es zeigt sich relativ schnell, dass das Hauptproblem darin besteht einen
>> Timer mit sehr geringem active-Stromverbrauch zu bauen
>
> Ein CD4536 braucht bei nicht zu schnellem RC Oszillator auch wenig Strom
> (wieviel realmüsste man ausprobieren) und blitzt nur kurz bei langen
> Pausen. Nur braucht er offiziell 3V.

Den dynamischen Strom darf man hier allerdings nicht vernachlässigen. 
Bei einem Oszillator werden die Eingägnge des Komparators mit analogen 
Spannungs zwischen "High" und "Low" betrieben. Dabei kann über die 
CMOS-Transistoren durchaus ein höhererer Querstrom fließen.

von A. S. (achs)


Lesenswert?

Tim  . schrieb:
>> Ich nehme bis 3,6 Volt immer die LF-Version (kostet
>> praktisch gleich viel), weil die im Leerlauf deutlich weniger ziehen,
>> über 3,6 Volt muss es aber der F-Typ sein.

Das wäre eigenartig, wenn die LF-typen  weniger Strom bei gleicher 
Spannung verbrauchen. Ist das so?
>
> Für den Preis des PIC12LF1822 bekommt man aber auch schon einen gut
> ausgerüsteten Cortex-M0 (z.B. STM32G031). Verstehe nicht ganz, warum der
> so teuer ist?

Vermutlich weil er veraltet ist. Die kleinen 8 Pin 16er kosten nicht Mal 
halb so viel und können 100 Mal mehr.

von bingo (Gast)


Lesenswert?

A. S. schrieb:
> Das wäre eigenartig, wenn die LF-typen  weniger Strom bei gleicher
> Spannung verbrauchen. Ist das so?

Von vielen PICs gibt es 2 Versionen: F und LF. Die F-Typen gehen meist 
von 1,8 bis 5,5 Volt und die LF-Typen gehen von 1,8 bis 3,6 Volt, 
absolute Maximalwerte sind 6,5 bzw. 4,0 Volt.  Bei den LF-Typen sind 
bestimmte Teile auf geringen Stromverbrauch getrimmt, nämlich der 
low-power-Oszillator (z.B. für den Watchdog) und der Oszillator für den 
Timer1. Je geringer die Taktfrequenz ist, umso grösser ist der 
Unterschied zwischen F und LF, das kann man in den Datenblättern schön 
sehen und auch leicht messen. Im Normalbetrieb bei 8, 16 oder 32 MHz ist 
der Unterschied geringer.

von A. S. (achs)


Lesenswert?

bingo schrieb:
> Bei den LF-Typen sind
> bestimmte Teile auf geringen Stromverbrauch getrimmt, nämlich der
> low-power-Oszillator (z.B. für den Watchdog) und der Oszillator für den
> Timer1.

Hast Du mal ein Beispiel? Also welcher Wert bei gleicher Spannung 
abhängig ist ob L oder LF?

Es ging ja hier um einen Spannungsbereich, den beide können, und da sehe 
ich z.B. im P12(L)F1840 auf die Schnelle nichts.

von Stephan S. (uxdx)


Lesenswert?

A. S. schrieb:
> Hast Du mal ein Beispiel? Also welcher Wert bei gleicher Spannung
> abhängig ist ob L oder LF?

Datenblatt 12F1840, Figure 31-1 und 31-2, oder Figure 31-19 und 31-20, 
oder Figure 31-31 und 31-32 da sind auf 1 Seite jeweils beide Typen 
abgebildet.

von A. S. (achs)


Lesenswert?

Stephan S. schrieb:
> Datenblatt 12F1840, Figure 31-1 und 31-2, oder Figure 31-19 und 31-20,
> oder Figure 31-31 und 31-32 da sind auf 1 Seite jeweils beide Typen
> abgebildet.

Whow, vielen Dank.

von Tim  . (cpldcpu)


Lesenswert?

Hier eine etwas detailliertere Beschreibung:

https://cpldcpu.wordpress.com/2021/02/07/ultra-low-power-led-flasher/

von Tiramisu (Gast)


Lesenswert?

Hi Tim,

waere es Dir moeglich, das Intel Hex File fuer den LED Flasher
hier zu posten?

Dankesehr!

von Tim  . (cpldcpu)


Angehängte Dateien:

Lesenswert?

Tiramisu schrieb:
> waere es Dir moeglich, das Intel Hex File fuer den LED Flasher
> hier zu posten?

Siehe Anhang. Der Programmer von Ralph kommt evtl. nicht mit den 
fuse-settings zurecht. Ich habe sie hier mal auskommentiert, da sie 
sowieso den default-settings entsprechen.

von Tiramisu (Gast)


Lesenswert?

>main.ihx

LAEUFT! .... Dankesehr! (auch "tiefrotdunkel-blinkend" mit
einer 20mA LED, die gelbe Low Current LEDs (1.8V(!)) und
eine 2,2Ah Tadiran 3,7V sind bestellt (derzeit ist die Tadiran AA
im Angebot bei Pollin, Eigenentladung wenige
Prozent in 10J, das entstehende Konstrukt sollte mich damit
"weit ueberleben" :-) )

>Der Programmer von Ralph kommt evtl. nicht mit den
>fuse-settings zurecht.

Zu diesem Verdacht bin ich im Laufe des Nachmittags auch gekommen.
Ich wollte mich ausgehend von Ralphs funktionierenden blink.c
Deinem "Ewigen Licht" codemeassig sukzessive annaehern und die Fuses
werden ja am Anfang gesetzt.

PS: Sorry wegen Umlauten, habe ein US-Tastatur-Layout.

von Tim  . (cpldcpu)


Angehängte Dateien:

Lesenswert?

Tiramisu schrieb:
> 2,2Ah Tadiran 3,7V sind bestellt (derzeit ist die Tadiran AA
> im Angebot bei Pollin, Eigenentladung wenige
> Prozent in 10J, das entstehende Konstrukt sollte mich damit
> "weit ueberleben" :-) )

Das sollte für Ewigkeiten reichen :)

Mein Aufbau blinkt mit einem Winzakku aus aus einem kabellosen Kopfhörer 
(im Bild oben Links) schon seit Januar.

von Energiesparer (Gast)


Lesenswert?

Tim  . schrieb:
>
> Die Bilder im Anhang zeigen meine Lösung. Die MCU lässt eine an PA4
> angeschlossene grüne LED mit einer Frequenz von 1.6 Hz für 75µs
> aufblitzen. Dieses ist gut sichtbar.

Hmm, ist es nicht effizienter den LED Strom etwas zu verringern und die 
Einschaltzeit zu erhöhen?

von Tim  . (cpldcpu)


Angehängte Dateien:

Lesenswert?

Energiesparer schrieb:
> Tim  . schrieb:
>>
>> Die Bilder im Anhang zeigen meine Lösung. Die MCU lässt eine an PA4
>> angeschlossene grüne LED mit einer Frequenz von 1.6 Hz für 75µs
>> aufblitzen. Dieses ist gut sichtbar.
>
> Hmm, ist es nicht effizienter den LED Strom etwas zu verringern und die
> Einschaltzeit zu erhöhen?

Das lässt sich schwer sagen, ohne den Arbeitspunkt genau zu kennen.

Wie man hier sehen kann, ist der Anteil des Stromverbrauchs durch die 
LED bereits geringer als der der MCU:

Beitrag "Re: Ultra Low Power LED Flasher mit Padauk PFS154"

Eine verringerung des LED Anteils hat also nur wenig vorteil.

Ich habe allerdings auch eine Version programmiert, die die 
Batteriespannung mit hilfe des internen Komparators bestimmt und damit 
die Anschaltzeitder LED korrigiert um sie mit möglichst konstanter 
Helligkeit leuchten zu lassen. Code anbei.

: Bearbeitet durch User
von Philipp Klaus K. (Firma: Albert-Ludwigs-Universität) (pkk)


Lesenswert?

Mir ist in der main.c
1
return 0; // to get rid of warning. This line is never executed

Aufgefallen. Wenn du eh die ganze Funktion in Assembler schreibst, 
brauchst du ja den von SDCC generierten Funktionsprolog und -epilog 
nicht, und kannst die Funktion als __naked deklarieren. damit 
verschwindet dann auch die Warnung wegen fehlendem return.

von Tim  . (cpldcpu)


Lesenswert?

Philipp Klaus K. schrieb:
> Mir ist in der main.c
> return 0; // to get rid of warning. This line is never executed
>
> Aufgefallen. Wenn du eh die ganze Funktion in Assembler schreibst,
> brauchst du ja den von SDCC generierten Funktionsprolog und -epilog
> nicht, und kannst die Funktion als __naked deklarieren. damit
> verschwindet dann auch die Warnung wegen fehlendem return.

Danke! Das kannte ich noch gar nicht.

von Apollo M. (Firma: @home) (majortom)


Lesenswert?

Tim  . schrieb:
> eine Version programmiert,

Was soll das denn "gutes" sein? Das lässt sich in drei Zeilen mit for 
ausdrücken!
1
void PulseLED(uint8_t cycles) {
2
3
  PA  |=1<<4;
4
5
  switch(cycles) {    
6
7
    case 1: PAC |=1<<4;PAC &=~(1<<4);break;
8
9
    case 2: PAC |=1<<4;__nop();PAC &=~(1<<4);break;
10
11
    case 3: PAC |=1<<4;__nop();__nop();PAC &=~(1<<4);break;
12
13
    case 4: PAC |=1<<4;__nop();__nop();__nop();PAC &=~(1<<4);break;
14
15
    case 5: PAC |=1<<4;__nop();__nop();__nop();__nop();PAC &=~(1<<4);break;
16
17
    case 6: PAC |=1<<4;__nop();__nop();__nop();__nop();__nop();PAC &=~(1<<4);break;
18
19
    case 7: PAC |=1<<4;__nop();__nop();__nop();__nop();__nop();__nop();PAC &=~(1<<4);break;
20
21
    case 8: PAC |=1<<4;__nop();__nop();__nop();__nop();__nop();__nop();__nop();PAC &=~(1<<4);break;
22
23
    default:
24
25
    case 9: PAC |=1<<4;__nop();__nop();__nop();__nop();__nop();__nop();__nop();__nop();PAC &=~(1<<4);break;  
26
27
  }  
28
}
 z.B. so
1
void PulseLED(uint8_t cycles) {
2
  PA  |=1<<4;
3
  for (uint8_t c=cycles-1; c; c--) __nop();
4
  PAC &=~(1<<4);  
5
}

Das ist natürlich zeitlich nicht ganz das selbe, aber für den Zweck 
wahrschein ok.

: Bearbeitet durch User
von Tim  . (cpldcpu)


Lesenswert?

Apollo M. schrieb:
> Das ist natürlich zeitlich nicht ganz das selbe, aber für den Zweck
> wahrschein ok.

Leider nicht. Es geht darum, die LED eine kontrollierte Anzahl von 
Zyklen anzuschalten. Du musst bedenken, dass der Core sehr langsam 
getaktet ist (~50 kHz). Jeder Zyklus zählt.

In Assembler hätte man das einfach mit einem indizierten Sprung machen 
können (pcadd). In C gibt es keine sinnvolle andere Option.

: Bearbeitet durch User
von Dieter D. (Firma: Hobbytheoretiker) (dieter_1234)


Lesenswert?

Tim  . schrieb:
> Energiesparer schrieb:
>> Hmm, ist es nicht effizienter den LED Strom etwas zu verringern und die
>> Einschaltzeit zu erhöhen?
> Das lässt sich schwer sagen, ohne den Arbeitspunkt genau zu kennen.

Niedrigerer Strom und etwas längere Leuchtdauer wäre zumindest weniger 
Stress für die LED. Aus der Ergononie gäbe es noch ein Diagramm in 
welchen Bereich bei gleicher Lichtenergie (Helligkeit x Zeit = konstant) 
ein Lichtblitz (Blinken) optimal wahrgenommen wird. Zugriff habe ich 
darauf nicht, kann also nur die Anregung beitragen.

: Bearbeitet durch User
von Tim  . (cpldcpu)


Lesenswert?

Dieter D. schrieb:
> Tim  . schrieb:
>> Energiesparer schrieb:
>>> Hmm, ist es nicht effizienter den LED Strom etwas zu verringern und die
>>> Einschaltzeit zu erhöhen?
>> Das lässt sich schwer sagen, ohne den Arbeitspunkt genau zu kennen.
>
> Niedrigerer Strom und etwas längere Leuchtdauer wäre zumindest weniger
> darauf nicht, kann also nur die Anregung beitragen.

Es gibt natürlich ein paar Tradeoffs, die man optimieren kann. Etwas 
schwieriger ist die Kontrolle des Arbeitspunktes der LED, die ja aktuell 
recht unkontrolliert über den Innenwiderstand der GPIO angesteuert wird.

Relevant ist vor allem, dass die Effizienz der grünen LED vom 
Vorwärtsstrom abhängt. Das hatte Ted Yapo mit der Tritiled auch genau 
untersucht. Alleine darüber ergibt sich eine Verbesserung bei längeren 
Pulsen mit niedrigerem Strom. Dem gegenüber steht allerdings, dass der 
Microcontroller dann mehr Strom verbraucht, weil er länger aktiv ist. 
Und der dominiert den Stromverbrauch bereits.

Man könnte es aber mal genauer ausrechnen :)

> Stress für die LED. Aus der Ergononie gäbe es noch ein Diagramm in
> welchen Bereich bei gleicher Lichtenergie (Helligkeit x Zeit = konstant)
> ein Lichtblitz (Blinken) optimal wahrgenommen wird. Zugriff habe ich

Damit habe ich mit tatsächlich schon einmal beschäftigt. Der Effekt, 
dass die wahrgenomme Helligkeit von der integrierten Lichtmenge abhängt, 
nennt sich "Bloch's Law". Dieser Zusammenhang ist für Lichtblitze bis zu 
ca 10-100 ms gültig. Danach tritt eine Sättigung, bzw. sogar Überhöhung 
ein ("Broca-Sulzer Phänomen").

Da unser Lichtblitz eine Dauer von weniger als 1 ms hat, gilt für das 
hier zu betrachtende Optimierungsproblem also, die integrierte 
abgegebene Lichtmenge zu maximieren.

https://journals.sagepub.com/doi/pdf/10.1177/2041669515593043
https://www.christophertyler.org/CWTyler/TylerPDFs/Gorea_Tyler_Bloch_JOSA_1986.pdf

: Bearbeitet durch User
von Wolfgang (Gast)


Lesenswert?

Tim  . schrieb:
> Der Effekt, dass die wahrgenomme Helligkeit von der integrierten
> Lichtmenge abhängt, nennt sich "Bloch's Law". Dieser Zusammenhang
> ist für Lichtblitze bis zu ca 10-100 ms gültig.

Auf dieser Basis funktioniert die Helligkeitssteuerung per PWM.
Die "10-100 ms" ist als Maximum für die Dauer der Blitze zu verstehen, 
nicht als Bereich für die Dauer - nur dass es da keine Missverständnisse 
gibt.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.