Hier haben wir einen elektronischen Bilderrahmen, der bei einem
Update-Intervall von 2 Minuten im realen Einsatz gut 3 Monate mit einer
AA-Zelle durchhalten sollte.
Als Display kommt ein 4.2"-ePaper-Modul von Waveshare zum Einsatz.
Es ist mir gelungen, eine Darstellung mit 16 Graustufen zu realisieren.
Das ist jenseits der von Waveshare spezifizierten Anwendung (Standard
ist ein Betrieb mit 1 Bit/Pixel). Da Waveshare die ePaper-Displays wohl
zukauft, ist nicht sicher, ob mglw. Displays mit anderer Technologie
angeboten werden könnten, die mit dem implementierten
Ansteuerungskonzept nicht harmonieren.
Tatsächlich ist das schon passiert:
Ich hatte zunächst ein Dreifarben-Display (weiß/gelb/schwarz)
ausgewählt, weil ich auch getestet habe, ob sich mit der gelben Farbe
evtl. ebenfalls etwas anfangen läßt. Dies macht allerdings m.E. für eine
universelle Bilddarstellung keinen Sinn (die Anzeige wird einfach nur
extrem gelbstichig), außerdem ist die Intensität der gelben Farbe nicht
vernünftig bzw. unabhängig von der Schwarz/Weiß-Darstellung steuerbar.
Da der Weißwert/Kontrast der dreifarbigen Displays selbst bei einfacher
S/W-Ansteuerung aber vergleichsweise nicht ganz so gut ist, habe ich's
auch mal mit der monochrome Display-Variante probiert.
Damit ist das Weiß zwar weißer, die Graustufen werden allerdings
überraschenderweise ziemlich grobkörnig dargestellt, wie mit einem sehr
grobkörnigen S/W-Filmmaterial. Das Dreifarb-Display zeigt keine solchen
Effekte, deshalb bin ich dabei geblieben.
Die ePaper-Displays haben konstruktionsbedingt eine gewisse
Temperaturabhängigkeit (immerhin verwenden sie ein mechanisches
Funktionsprinzip, die Farbkügelchen müssen ja in einer Flüssigkeit
bewegt werden). Das von Waveshare original bereitgestellte Setup
berücksichtigt die Displaytemperatur in 9 Stufen und paßt die
Display-Update-Parameter entsprechend an (im Wesentlichen verlängert
sich die benötigte Updatedauer, je niedriger die Temperatur ist). Ich
habe keine Klimakammer, mit der ich das entsprechend reproduzierbar
nachbauen könnte, deshalb gibt es nur einen Parametersatz für die
übliche Zimmertemperatur.
Eine konstante Spannungsversorgung ist ebenfalls ratsam, das Display
arbeitet zwar auch noch mit einer geringeren Versorgungsspannung,
Änderungen der Grauwerte sind bei schwankender Spannung aber
unvermeidbar. Ein Spannungsstabilisator ist deshalb erforderlich, direkt
aus einer 3V-LiMno2-Zelle macht's keinen Sinn, mit 3,6V-Lithium-Thionyl
(evtl. auch Akku) + LDO wird's wohl gehen, ich habe mich für Alkaline-AA
und Step-Up-Wandler entschieden.
Nach dem PowerOn-Reset wird das Display einmal mit den Factory-Settings
gelöscht, das dauert gute 10 Sekunden. Für den normalen Betrieb habe ich
die LookUp-Tables zeitlich optimiert, bin aber beim prinzipiellen
Verfahren geblieben - in der Hoffnung, damit die Lebensdauer des
Displays nicht zu reduzieren (ob's klappt, wird sich vmtl. erst nach
etlichen Monaten Dauerbetrieb zeigen). Mit irgendwelchen wilden
Parameterwerten (etwa höhere Boosterspannung und längeren Einzelphasen)
ließe sich die benötigte Dauer mglw. noch verringern, aber was nützt
das, wenn dann nach einiger Zeit die Farbkügelchen anders polarisiert
werden oder vielleicht irgendwo Elektrolyse der Elektroden einsetzt...
Ich denke, die hier gezeigte S/W- bzw. Graustufen-Implementation ist
aktuell Stand der Technik,vollfarbfähige ePapers gibt es nach wie vor
nur als Ankündigung oder Messemuster, Module für den Hobbyisten schon
gar nicht.
https://youtu.be/znfEyW1eg7Y
Als Controller habe ich einen Pro-Micro-Clone (Atmega 32u4, 3,3 V, 8
MHz, 32 k Flash, 2.5 k RAM) eingesetzt, im Prinzip ginge es mit jedem
Atmega ab 32 k Flash und 2 k RAM, wenn die Sektor-Puffergröße für das
Lesen von der SD-Card reduziert wird. Der Programmcode an sich ist gar
nicht so umfangreich - ca. 8 kBytes - aber es sind noch zwei Bilder für
Statusanzeigen mit dabei, die tragen ziemlich auf...
Die LEDs und der Onboard-Spannungsregler auf dem Pro-Micro-Breakout sind
rausgeknackt, um unnötigen Stromverbrauch zu vermeiden.
Die Bilder werden auf einer (Micro-)SD-Card als monochrome JPEGs
abgelegt, die SD-Card wird via 8-Bit-Bustreiber (74HC245) angesteuert
sowie mit Strom versorgt und kann damit komplett abgeschaltet werden.
Die dekodierten Bilddaten werden in einem SPI-RAM (64 kByte, 23LC512)
zwischengespeichert, es ist nicht möglich, sie gleich im Framebuffer des
ePaper-Moduls abzulegen.
Mittels Fotodiode BPW34 wird die Umgebungshelligkeit geprüft und das
Display-Update gestoppt, sobald es zu dunkel geworden ist, das kommt der
Batterielaufzeit zugute.
Als Step-Up-Wandler auf 3,3 V kommt der Sparkfun-Breakout PRT-10967 mit
NCP 1402 zum Einsatz. Der Leerlaufstrom ist damit deutlich geringer als
mit entsprechenden Pololu-Teilen, das ganze Gerät zieht zwischen den
Display-Updates ca. 80 uA aus einer vollen AA-Zelle. Der Batteriehalter
ist von Bulgin.
Beim Prototypen ist das SPI-RAM und der Spannungswandler-BreakOut unter
dem ProMicro montiert, kleiner bekommt man die Steuerung mit Komponenten
im 2.54 mm-Raster nicht mehr.
Das Schaltungskonzept sollte auch mit einem 7.5"-ePaper-Modul (640x375
Pixel) verwendbar sein, in diesem Fall wird aber ein 128 kByte-SPI-RAM
benötigt (23LC1024), mit dem größeren Display wäre sicher auch Platz für
zwei AA-Zellen.
Die Firmware ist in Assembler kodiert (AVR Studio 4.19-Projekt).
Der JPEG-Dekoder ist eine angepaßte Version aus dieser Veröffentlichung
Beitrag "Fast JPEG decoder on AT(x)mega" und braucht inkl.
Datei- und SPI-RAM-Zugriff ca. 1 Sekunde für die Dekodierung eines
Bildes (400x300 Pixel) bei 8 MHz Controllertakt. Der Atmega geht auch
während der Display-Update-Phasen immer wieder in den Powersave-Modus
und wird über die BUSY-Leitung vom Display geweckt, wenn der jeweilige
Vorgang abgeschlossen wurde.
Der SD-Card/Filesystem-Treiber ist eine Mischung aus Petite FS und FAT
FS (ElmChan), ich habe auf vFAT erstmal verzichtet, Datei- und Pfadnamen
sind also im 8.3-Format (Großschreibung) anzugeben. In den Beispielen
wird eine 4 GByte-Micro-SD-Card mit FAT32 verwendet.
Die Pfadnamen der anzuzeigenden Bilder werden aus der Datei PICTURES.TXT
im Root-Verzeichnis gelesen.
Die Bilddarstellung kann mit der Datei CONTROL.TXT (ebenfalls im
Root-Verzeichnis) kontrolliert werden.
Es gibt zwei Optionen:
timer=<Verzögerung bis zur Anzeige des nächsten Bildes in Sekunden,
Default sind 120 Sekunden, Maximum 2040 Sekunden=34 Minuten>
mode=<random|>
Der Atmega geht nach der Dekodierung/Anzeige eines Bildes in den
Powersave-Modus und läßt sich vom Watchdog-Interrupt alle 8 Sekunden
aufwecken. Die Granularität des timer-Parameters ist dementsprechend 8
Sekunden.
Mit mode=random wird ein zufälliges Bild zur Anzeige ausgewählt, mit
jedem anderen Parameterwert oder wenn mode gar nicht angegeben wird,
erfolgt die Anzeige sequentiell so wie in PICTURES.TXT aufgeführt.
Im Random-Mode wird im Übrigen geprüft, ob das aktuell gewählte Bild
bereits unter den fünf zuvor angezeigten Bildern gewesen ist. In diesem
Fall wird ein anderes Bild gewählt.
Die Firmware erwartet die Bilder im korrekten Format, es wird nichts
skaliert, gedithert o. dgl. (die Schaltung hat kein Gramm Fett zuviel,
für größere Bilder ist kein Platz; außerdem müßte die Skalierung usw.
jedesmal auf's Neue durchgeführt werden, das kostet wieder Energie; ein
SPI-RAM wäre datenzugriffstechnisch für solche Bildmanipulationen auch
nicht direkt optimal).
"Korrekt" ist eine Auflösung von 400x300 Pixeln, monochrom mit 16
Graustufen im JPEG-Format.
Der grundlegende Workflow mit GIMP sieht bspw. so aus:
Bild-->Modus-->Graustufen
Bild-->Bild skalieren 400x300
Bild-->Modus-->Indiziert-->
Optimale Palette erzeugen, max. Anzahl der Farben: 16
+ Rasterung: Floyd Steinberg (normal)
Bild-->Modus-->Graustufen
Exportieren als JPEG, "Progressiv" darf nicht verwendet werden
Bei den meisten Bildern ist es empfehlenswert, zusätzlich noch unscharf
zu maskieren und einen Weißabgleich durchzuführen (alles noch als
Farbbild), um den Kontrast des S/W-Bildes zu steigern. Abhängig vom
Bildinhalt kann es sich lohnen, weitere Effekte zu probieren
(Kontrastspreizung u.ä.).
Das alles läßt sich mit GIMP auch verscripten, etwa mit Batch Image
Manipulation oder mit Script-Fu.
Mit der Mechanik hatte ich's noch nie so... Das Gehäuse ist aus
lasergeschnittenen Acrylglasteilen zusammengeklebt (die Klebflächen
sind, äh, optimierbar...) das ginge mit Sicherheit eleganter. Richtig
edel wäre ein Acryl-Spritzgußgehäuse mit polierter Frontpartie,
integriertem Batteriefach (ggf. sogar 4xAA für LDO und > 1 Jahr
Laufzeit) und ordentlichem Schlitz für die SD-Card, aber das ist als
Einzelstück illusorisch. Ich würde noch nichtmal die Konstruktion
hinkriegen (hab für die Acrylplatten mit ein paar CAD-Programmen
gespielt und die Flinte nach kürzester Zeit ins Korn geworfen und
Millimeterpapier genommen :-/).
Die Dokumentationslage zum Displaycontroller ist ziemlich dürftig, von
Waveshare gibt's offiziell nur das Allernötigste, um das Display im
Standardmodus steuern zu können (insbesondere die Informationen zur
Struktur der LookUp-Tables werden explizit zurückgehalten und wurden aus
dem aktuellen Datenblatt entfernt).
Der serielle Daten-"Eingang" P_MOSI ist effektiv bidirektional, der
Controller liefert bei einigen Kommandos Informationen zurück.
In der fertigen Bilderrahmen-Firmware werden keine Lesezugriffe
verwendet (man könnte aber z.B. den eingebauten Temperatursensor
auslesen und die Controller-Settings anpassen), während der Entwicklung
war diese Möglichkeit jedoch sehr hilfreich.
Ich habe das so realisiert, daß das SPI-Interface am Atmega nach dem
Senden des Kommandos und eventueller Parameter deaktiviert und der
MOSI-Pin auf Input konfiguriert wurde. Das Einlesen der Daten erfolgte
dann mit einem Soft-SPI, man könnte für solche Zwecke natürlich auch
gleich alles per Soft-SPI machen.
Mit dieser Methode habe ich das OTP-ROM ausgelesen. Die enthaltenen
Informationen können als Aufsetzpunkt für eigene Definitionen (LUT etc.)
verwendet werden, man muß das Rad nicht neu erfinden.
Hier ist mal die Beschreibung der Werte im OTP-ROM aus dem von mir
eingesetzten Display:
1
Offset Wert Beschreibung
2
000 A5 Check code, enable key
3
001 CB LUT Revision
4
002 05 Displaytemperatur <=5 Grad für LUT-Definition 0
5
003 0A Displaytemperatur <=10 Grad für LUT-Definition 1
6
...
7
009 28 Displaytemperatur <=40 Grad für LUT-Definition 7
8
00A 7F Ende, LUT-Defintion 8 (oberhalb 40 Grad)
9
10
010 0190 X-Auflösung (400)
11
012 012C Y-Auflösung (300)
12
014 53 "S"
13
015 30 "0"
14
016 31 "1"
15
017 30 "0"
16
018 02 ???
17
18
020 A5 Check code, enable key
19
021 0F Parameter für PANEL_SETTING
20
022 00 Parameter für POWER_OFF_SEQUENCE_SETTING
21
023 D7 1. Parameter für BOOSTER_SOFT_START
22
024 D7 2. Parameter für BOOSTER_SOFT_START
23
025 1E 3. Parameter für BOOSTER_SOFT_START
24
026 00 Parameter für TEMPERATURE_SENSOR_SELECTION
25
027 77 Parameter für VCOM_AND_DATA_INTERVAL_SETTING
26
028 22 Parameter für TCON_SETTING
27
029 0190 1. Parameter für RESOLUTION_SETTING (HRES)
28
02B 012C 2. Parameter für RESOLUTION_SETTING (VRES)
29
02D 0000 1. Parameter für GSST_SETTING (HST)
30
02F 0000 2. Parameter für GSST_SETTING (VST)
31
031 00 Parameter für CASCADE_SETTING
32
032 00 Parameter für POWER_SAVING
33
033 00 Parameter für FORCE_TEMPERATURE
34
35
0F0 A5 Check code, enable key
36
0F1 FC ??
37
0F2 E1
38
0F3 F0
39
0F4 F8
40
0F5 F8
41
0F6 F8
42
0F7 F0
43
0F8 F0
44
0F9 F0
45
0FA F0
46
0FB F0
47
0FC F0
48
0FD F0
49
0FE F2
50
0FF FC
51
52
LUT-Definition 0
53
100 3C Parameter für PLL_CONTROL
54
der 1. Parameter ist immer 3
55
101 00 2. Parameter für POWER_SETTING
56
102 2B 3. Parameter für POWER_SETTING
57
103 2B 4. Parameter für POWER_SETTING
58
104 12 5. Parameter für POWER_SETTING
59
105 16 Parameter für VCM_DC_SETTING
60
106 LUT_FOR_VCOM
61
00 B1 B1 00 0C 01
62
00 0D 01 20 02 06
63
00 0A 0A 05 05 19
64
00 05 05 03 03 1E
65
00 0D 0A 20 12 06
66
00 06 1E 1E 01 0E
67
00 09 09 00 00 01
68
00 00
69
132 LUT_WHITE_TO_WHITE
70
90 B1 B1 00 0C 01
71
40 0D 01 20 02 06
72
66 0A 0A 05 05 19
73
99 05 05 03 03 1E
74
80 0D 0A 20 12 06
75
00 06 1E 1E 01 0E
76
00 09 09 00 00 01
77
15C LUT_BLACK_TO_WHITE
78
A0 B1 B1 00 0C 01
79
48 0D 01 20 02 06
80
66 0A 0A 05 05 19
81
99 05 05 03 03 1E
82
06 0D 0A 20 12 06
83
BC 06 1E 1E 01 0E
84
F0 09 09 00 00 01
85
186 LUT_WHITE_TO_BLACK
86
90 B1 B1 00 0C 01
87
40 0D 01 20 02 06
88
66 0A 0A 05 05 19
89
99 05 05 03 03 1E
90
80 0D 0A 20 12 06
91
00 06 1E 1E 01 0E
92
00 09 09 00 00 01
93
1B0 LUT_BLACK_TO_BLACK
94
62 B1 B1 00 0C 01
95
09 0D 01 20 02 06
96
66 0A 0A 05 05 19
97
99 05 05 03 03 1E
98
11 0D 16 1C 0A 06
99
00 06 1E 1E 01 0E
100
00 09 09 00 00 01
101
200 LUT-Definition 1
102
...
103
900 LUT-Definition 8
Mit der LUT wird der Spannungsverlauf an den Elektroden (die sog.
Waveform) definiert.
Die LUTs sind prinzipiell vergleichbar strukturiert, LUT_FOR_VCOM nimmt
jedoch eine Sonderstellung ein und ist 44 Bytes lang.
1
Bit
2
Offset 76543210 Beschreibung
3
00 AABBCCDD jeweils 2 Bit Level-Select
4
00: VCM_DC
5
01: VDH+VCM_DC (VCOMH)
6
10: VDL+VCM_DC (VCOML)
7
11: Floating
8
01 AAAAAAAA Anzahl der Frames für Level A
9
02 BBBBBBBB Anzahl der Frames für Level B
10
03 CCCCCCCC Anzahl der Frames für Level C
11
04 DDDDDDDD Anzahl der Frames für Level D
12
05 XXXXXXXX Wiederholungszähler (0...255)
13
06...11 gleiche Struktur wie 00...05
14
12...17 gleiche Struktur wie 00...05
15
18...23 gleiche Struktur wie 00...05
16
24...29 gleiche Struktur wie 00...05
17
30...35 gleiche Struktur wie 00...05
18
36...41 gleiche Struktur wie 00...05
19
42 -YYYYYYY Bit 0...6 für die sieben Phasen
20
der Waveform
21
0: not all Gate ON
22
1: all Gate ON
23
43 -ZZZZZZZ Bit 0...6 für die sieben Phasen
24
der Waveform
25
0: no VCOM High Voltage
26
1: VCOM High Voltage
Die übrigen (Source-)LUTs sind jeweils 42 Bytes lang und werden wie
folgt kodiert:
1
Bit
2
Offset 76543210 Beschreibung
3
00 AABBCCDD jeweils 2 Bit Level-Select
4
00: GND
5
01: VDH
6
10: VDL
7
11: VDHR
8
01 AAAAAAAA Anzahl der Frames für Level A
9
02 BBBBBBBB Anzahl der Frames für Level B
10
03 CCCCCCCC Anzahl der Frames für Level C
11
04 DDDDDDDD Anzahl der Frames für Level D
12
05 XXXXXXXX Wiederholungszähler (0...255)
13
06...11 gleiche Struktur wie 00...05
14
12...17 gleiche Struktur wie 00...05
15
18...23 gleiche Struktur wie 00...05
16
24...29 gleiche Struktur wie 00...05
17
30...35 gleiche Struktur wie 00...05
18
36...41 gleiche Struktur wie 00...05
Die Anzahl der Frames und die Wiederholungszähler sollten normalerweise
in allen fünf LUTs identisch kodiert werden, die LUTs unterscheiden sich
dann nur bei den Level-Selects.
Die vier "Source"-LUTs werden bei einem S/W-Display standardmäßig so
verwendet, daß sowohl der alte als auch der neue Bildinhalt im
Display-RAM stehen Der Displaycontroller braucht dann nur die geänderten
Pixel anzusteuern (schwarz-->weiß und umgekehrt), ein vorheriges Löschen
des Displayinhalts ist nicht erforderlich.
Schon bei der normalen Ansteuerung des Dreifarb-Displays funktioniert
das nicht mehr so. Dabei wird von einem vollständig gleichfarbigen
Displayinhalt ausgegangen (üblicherweise Weiß) und die Bildanteile für
die Vordergrund-Farben (Schwarz und Gelb bzw. Rot) werden ins
Display-RAM geladen.
Pro Pixel gibt es damit zwei Bits, Bit 0 bspw. für Schwarz und Bit 1 für
Gelb. Mit der Bitkombination wird eine der vier LUTs addressiert, die
dann die Farbe des Pixels setzt.
Das Verfahren ist ziemlich flexibel (nur deshalb konnte ich die
Graustufendarstellung realisieren).
Beispiel:
00: Weiß
01: Schwarz
10: Gelb
11: Gelb (genausogut könnte aber auch Schwarz die höhere Priorität
haben, es hängt nur von der Definition der Waveform in der LUT ab)
Interessant ist übrigens die Methode, mit der die verschiedenen Farben
kontrolliert werden.
Eine begründete Vermutung lautet:
Die schwarzen und weißen Farbpartikel sind verhältnismäßig klein (können
sich also schnell bewegen), benötigen aber eine vergleichsweise hohe
Spannungsdifferenz zwischen VCOM und Source.
Die roten/gelben Farbpartikel sind größer und träger, bewegen sich aber
schon bei einer kleineren Spannungsdifferenz. Das ist wohl der Grund,
warum die Dreifarbdisplays eine erheblich längere Zeit für das Update
brauchen.
Für die Graustufendarstellung werden die LUTs entsprechend so kodiert,
daß die vier Bits pro Bildpunkt mit zwei Display-Updates - jeweils zwei
Bits für die LUT-Adressierung wie oben gezeigt - die Intensität der
schwarzen "Farbe" für dieses Pixel setzen (ausgehend von einem komplett
weißen Displayinhalt). Das ist der Trick, der Rest ist Handwerk...
Horst M. schrieb:> Als Step-Up-Wandler auf 3,3 V kommt der Sparkfun-Breakout PRT-10967 mit> NCP 1402 zum Einsatz. Der Leerlaufstrom ist damit deutlich geringer als> mit entsprechenden Pololu-Teilen, das ganze Gerät zieht zwischen den> Display-Updates ca. 80 uA aus einer vollen AA-Zelle.
danke dafür!
tolles Projekt, ich wollte schon "meckern" aber es ist sehr durchdacht!
Mein erstes richtiges Projekt mit DC/DC Wandler war ein Reinfall, was
nutzt es wenn der µC schläft und schön sparsam ist wenn der Wandler die
Zellen leersaugt.
Horst M. schrieb:> Hier haben wir einen elektronischen Bilderrahmen, der bei einem> Update-Intervall von 2 Minuten im realen Einsatz gut> 3 Monate mit einer AA-Zelle durchhalten sollte.
Ooops, das war sehr konservativ geschätzt.
Heute, nach über 9 Monaten mit einer AA-Zelle vom Discounter, habe ich
den "Low Battery"-Screen gesehen. Das Gerät hat während der üblichen
Bürozeiten gearbeitet - also werktäglich ca. 8 Stunden mit zwei Minuten
Update-Intervall - und stand sonst im Dunkeln (=Stop des
Display-Updates, siehe Beschreibung).
Sehr wahrscheinlich hat mein Schätzometer beim Messen des Leerlaufstroms
im 200uA-Meßbereich bereits soviel Spannungsabfall eingebracht, daß der
StepUp-Wandler deutlich mehr gezogen hat als bei direkter Verbindung zur
Batterie.
Nach nun einigen zehntausend Display-Updates lassen sich keine negativen
Effekte (WearOut, Shadowing etc.) erkennen, die optimierte Waveform und
die anderen Settings scheinen also das Display nicht zu stressen.
Abstürze gab es auch keine, die Firmware ist wohl stabil genug.
9 Monate - da habe ich gar kein schlechtes Gewissen, eine Primärzelle
einzusetzen...
Horst M. schrieb:> Heute, nach über 9 Monaten mit einer AA-Zelle vom Discounter, habe ich> den "Low Battery"-Screen gesehen.
Naja, das ist schon sehr schön, aber da ginge sicher noch mehr. Deine
Begründungen, warum du eine Konstantspannungsquelle unbedingt zu
brauchen glaubst, sind nämlich sehr, sehr dünn.
Und du kannst davon ausgehen, dass der weit überwiegende Teil der
verbrauchten Energie genau in diesem Ding verheizt wurde.
D.h.: da ist noch deutlich mehr drin. Im Prinzip läuft es schlicht
darauf hinaus, Kennlinienfelder für das Display zu ermitteln, sowohl was
die Abhängigkeit von der Temperatur als auch von der Spannung betrifft.
Das kann man mit einer Webcam als billigem Sensor leicht automatisieren
(wenn kein ausführliches DB des eigentlichen Displays zur Verfügung
steht, denn das sollte diese Abhängigkeiten ohnehin umfassend
dokumentieren).
Woher auch immer: Wenn man die Kennlinienfelder hat, kann man den
Konstanter wegwerfen und die nötigen Anpassungen bei der Ansteuerung
entsprechend der aktuellen Temperatur und Spannung in Software
erledigen.
BTW: Man braucht nicht unbedingt eine Klimakammer für solche Sachen,
auch wenn die natürlich ein deutlich komfortableres Arbeiten ermöglicht.
Das geht zur Not auch mit einfachen haushaltsüblichen Gerätschaften wie
Tiefkühlfach/-truhe und Backofen, jedenfalls für den Temperaturbereich,
der hier in Mitteleuropa relevant ist.
Echt ein tolles Projekt. Ich hatte bisher ein 4.3 UART Waveshare Display
als Bilderrahmen im Einsatz, da dieses wenigstens 2bit Grayscale
unterstützt.
Habe das Projekt hier nachgebaut, und muss sagen, mit 16 Graustufen
sieht das trotz der deutlich geringeren Auflösung besser aus.
Ein Traum wäre jetzt, das mit einem der größeren Displays, die auch eine
bessere Auflösung haben zu realisieren. Es gibt recht günstig das neue
7,5 Zoll ePaper mit 880x528 Pixeln.
Oder das leider kaum in Deutschland bisher nicht verfügbare 12,48 Zoll
Display, das bereits in einem ansprechenden Rahmen geliefert wird (wird
wegen der hohen Auflösung als vier kleine virtuelle Displays
angesprochen).
Leider unterstützt die Hardware von Waveshare hier wieder nur 1bit
Farbtiefe, was den Einsatz als Bilderrahmen wieder sehr einschränkt.
Leider kann ich kein Assembler, sonst würde ich mal versuchen solch ein
Projekt anzugehen.
Aber Kompliment für das, was hier geschaffen wurde!
Grüße,
Peter
Joachim B. schrieb:> Mein erstes richtiges Projekt mit DC/DC Wandler war ein Reinfall, was> nutzt es wenn der µC schläft und schön sparsam ist wenn der Wandler die> Zellen leersaugt.
Ob es die Ultra-Low-Quiescence-Schaltregler mit 500nA Ruhestrom auch
schon for 2 Jahren gab? :thinking:
Mampf F. schrieb:> Ob es die Ultra-Low-Quiescence-Schaltregler mit 500nA Ruhestrom auch> schon for 2 Jahren gab? :thinking:
k.A. aber ich baute diesen Fehler vor über 13 Jahren, definitiv mit dem
falschen Wandler und definitiv im falschen Design, damals fand ich den
kapazitiven buck/boost MAX682 geeignet und ich lernte, ER IST ES NICHT!
Heute würde ich das anders machen.