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
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
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.
Harald schrieb: > C34499 LCSC sagt Discontinued, Hubei Kento sagt This product is no longer available, und ein Datenblatt habe ich nicht gefunden.
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.
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.
Habe es im Browserverlauf wiedergefunden https://datasheet.lcsc.com/szlcsc/Everlight-Elec-19-213-Y2C-CQ2R2L-3T-CY_C72038.pdf
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.
Harald schrieb: > Habe es im Browserverlauf wiedergefunden Hmm, andere Grösse, andere Farbe, andere Typennummer, anderer Hersteller, das ist wohl nicht die gleiche.
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.
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.
Ergänzend: 250uA 2,4V 1mA 2,45V 2mA 2,5V 5mA 2,8V 10mA 2,9V
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 |
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
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
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.
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)
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.
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.
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.
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.
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.
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.
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.
Hier eine etwas detailliertere Beschreibung: https://cpldcpu.wordpress.com/2021/02/07/ultra-low-power-led-flasher/
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.
>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.
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.
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?
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
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.
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.
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
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
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
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
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.
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.