Ultra Low Power LED Flasher mit Padauk PFS154

[Tim . (cpldcpu)]

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.

[Tim . (cpldcpu)]

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.

unsigned char _sdcc_external_startup(void)
{
  PDK_SET_FUSE(FUSE_IO_DRV_LOW);  // Set output driving strength to low
  
  CLKMD =  CLKMD_ILRC | CLKMD_ENABLE_ILRC | CLKMD_ENABLE_IHRC; 
  CLKMD =  CLKMD_ILRC | CLKMD_ENABLE_ILRC ; 

    // Note: it is important to turn off IHRC only after clock settings
    // have been updated. Otherwise the CPU stalls.
  return 0; // perform normal initialization
}

void main(void)
{
  // Stopsys with 5V: 0.5 µA
  // The watchdog cannot wake up from stopexe!!

  PADIER = 0; // disable pins as wakeup source
  PBDIER = 0; // Also port B needs to be disabled even if it is not connected
        // to the outside of the package. touching the package can introduce 
        // glitches and wake up the device

  INTEN = 0;  // Make sure all interrupts are disabled
  INTRQ = 0;

  MISC = MISC_FAST_WAKEUP_ENABLE;  // Enable faster wakeup (45 clocks instead of 3000)
                   // This is important to not waste energy, as 40µA bias is already added during wakeup time

  // Configure timer two for output on PA3
  // --> Works, timer2 and 2 can be used for PWM while CPU is in STOPEXE mode
  // It appears that also timer 2 can wake up the CPU. This is not maskable?

  TM2C  = TM2C_CLK_ILRC | TM2C_MODE_PWM;  // Oscilator source for timer 2 is LRC (53 kHZ)
  TM2CT = 0;
  TM2S  = TM2S_PRESCALE_DIV16 | TM2S_SCALE_DIV8; // Divide clock by 16*7=112 -> 53 kHz / 122 = 414 Hz    
  TM2B  = 1;  // PWM threshold set to 1. The PWM event will trigger the wakeup. Wakeup occurs with 414 Hz / 256 = 1.66 Hz

  PA    = 1<<4;  // LED is on PA4, set all other output to zero.
  PAPH   = 0;   // Disable all pull up resistors
  PAC    = 0;     // Disable all outputs
           // Note: There is no series resistor for the LED
           // The LED current is limited to 2-4 mA by LOW IO driving setting
           // See Setction 4.14 (p24) in PFS154 manual
           // The output is disabled when the LED is off to avoid leakage

  for (;;) {  
    PAC |=1<<4;  // Enable LED output (It's set to High)
    __nop();
    __nop();
    __nop();
    PAC &=~(1<<4); // Disable LED output after 4 cycles => 4/53 kHz = 75.5 µS
    __stopexe();
  }
}

[Harald (Gast)]

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.

[MaWin (Gast)]

Harald schrieb:
> C34499

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

[Tim . (cpldcpu)]

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.

[Harald (Gast)]

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.

[Harald (Gast)]

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

[Tim . (cpldcpu)]

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.

[MaWin (Gast)]

Harald schrieb:
> Habe es im Browserverlauf wiedergefunden

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

[Harald (Gast)]

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.

[Harald (Gast)]

Kaltweiß nicht Kalkweiß.

[Harald (Gast)]

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.

[Harald (Gast)]

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

[bingo (Gast)]

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"

; blitz_1822.asm fuer PIC12LF1822
; blitzt 2 LEDs und schläft dann 4 sec, wird durch WDT neu gestartet

    list p=16f1822
    #include <p16f1822.inc>

    ERRORLEVEL -302             ; schaltet Bank-Warnungen ab

    __CONFIG    _CONFIG1, _FOSC_INTOSC & _WDTE_ON & _PWRTE_OFF & _MCLRE_OFF & _CP_OFF & _CPD_OFF & _BOREN_OFF & _CLKOUTEN_OFF & _IESO_OFF & _FCMEN_OFF & 0x3FFF
    __CONFIG    _CONFIG2, _WRT_OFF & _PLLEN_OFF & _STVREN_OFF & _BORV_19 & _LVP_OFF & 0x3FFF

    cblock 0x20                 ; RAM
    cnt
    endc

#define LED0        PORTA, 0    ; LED 0
#define LED1        PORTA, 1    ; LED 1

bank0 macro
    movlb   0x00                ; Bank 0
    endm

bank1 macro
    movlb   0x01                ; Bank 1
    endm

bank2 macro
    movlb   0x02                ; Bank 2
    endm

bank3 macro
    movlb   0x03                ; Bank 3
    endm

bank4 macro
    movlb   0x04                ; Bank 4
    endm

    org     0x00

init
    bank3
    clrf    ANSELA              ; Port A digital
    bank1
    clrf    TRISA               ; Port A alle output
    bank0
    clrf    PORTA               ; Ports initialisieren
    bank2
    clrf    LATA                ; Ports initialisieren
    bank1
    movlw   B'00000010'         ; Oszillator 31 kHz INTOSC
    movwf   OSCCON
    clrf    INTCON              ; Interrupt disable
    movlw   B'00011001'         ; WDT auf 1:2^17 = 4 sec
    movwf   WDTCON

;***********************************************************************

    bank0

main
    bsf     LED0
    call    wait1
    bcf     LED0
    call    wait1
    bsf     LED1
    call    wait1
    bcf     LED1

    sleep
    nop                         ; nach sleep 1x nop !

    goto main

wait1
    movlw   0x20                ; 0x20 sind ca 12 msec bei 31 kHz
    movwf   cnt
    decfsz  cnt, f
    goto    $-1
    return

    end

[Tim . (cpldcpu)]

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?

[Tim . (cpldcpu)]

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.

[bingo (Gast)]

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.

[Tim . (cpldcpu)]

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)

[MaWin (Gast)]

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.

[Tim . (cpldcpu)]

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.

[A. S. (Gast)]

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.

[bingo (Gast)]

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.

[A. S. (Gast)]

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.

[Stephan S. (uxdx)]

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.

[A. S. (Gast)]

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.

[Tim . (cpldcpu)]

Hier eine etwas detailliertere Beschreibung:

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

[Tiramisu (Gast)]

Hi Tim,

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

Dankesehr!

[Tim . (cpldcpu)]

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.

[Tiramisu (Gast)]

>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.

[Tim . (cpldcpu)]

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.

[Energiesparer (Gast)]

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?

[Tim . (cpldcpu)]

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.

[Philipp Klaus K. (pkk)]

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.

[Tim . (cpldcpu)]

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.

[Apollo M. (Firma: @home) (majortom)]

Tim  . schrieb:
> eine Version programmiert,

Was soll das denn "gutes" sein? Das lässt sich in drei Zeilen mit for 
ausdrücken!

void PulseLED(uint8_t cycles) {

  PA  |=1<<4;

  switch(cycles) {    

    case 1: PAC |=1<<4;PAC &=~(1<<4);break;

    case 2: PAC |=1<<4;__nop();PAC &=~(1<<4);break;

    case 3: PAC |=1<<4;__nop();__nop();PAC &=~(1<<4);break;

    case 4: PAC |=1<<4;__nop();__nop();__nop();PAC &=~(1<<4);break;

    case 5: PAC |=1<<4;__nop();__nop();__nop();__nop();PAC &=~(1<<4);break;

    case 6: PAC |=1<<4;__nop();__nop();__nop();__nop();__nop();PAC &=~(1<<4);break;

    case 7: PAC |=1<<4;__nop();__nop();__nop();__nop();__nop();__nop();PAC &=~(1<<4);break;

    case 8: PAC |=1<<4;__nop();__nop();__nop();__nop();__nop();__nop();__nop();PAC &=~(1<<4);break;

    default:

    case 9: PAC |=1<<4;__nop();__nop();__nop();__nop();__nop();__nop();__nop();__nop();PAC &=~(1<<4);break;  

  }  
}

 z.B. so

void PulseLED(uint8_t cycles) {
  PA  |=1<<4;
  for (uint8_t c=cycles-1; c; c--) __nop();
  PAC &=~(1<<4);  
}

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

[Tim . (cpldcpu)]

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.

[Dieter D. (Firma: Hobbytheoretiker) (dieter_1234)]

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.

[Tim . (cpldcpu)]

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

[Wolfgang (Gast)]

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.