Für eine kleine Uhr bin ich auf der Suche nach einem Low Power uC, am besten ein Atmel oder ein Pic. Versorgt wird die Uhr mit einer CR2032, sollte also mit 3V laufen. I2C mit 400kHz bis 1Mhz sollte auch drin sein. Möglichst kleine Bauform wäre auch nicht schlecht Als RTC kommt aller vorraussicht ein M41T62LC6F zum Einsatz, hat damit schonmal jemand Erfahrung gemacht ?
Wenn du nichts gegen Cortex-M0(/M3) hast, dann guck dir mal die EFM Geckos von SILabs an: http://www.silabs.com/products/mcu/32-bit/Pages/32-bit-microcontrollers.aspx Die finde ich recht schick und low-power.
LiPoFeFaFu schrieb: > Versorgt wird die Uhr mit einer CR2032, sollte also mit 3V laufen. Die hat kurz vor leer nur ca. 2 Volt Spannung übrig. Das dürfte für ältere AVR und PIC zuwenig sein. > I2C mit 400kHz bis 1Mhz sollte auch drin sein. Das wird wohl nix. Eine 2032 liefert nur ca. 1mA als "Dauerlast". Die damit erreichbaren µC Taktfrequenzen dürften 1 MHz I²C eher nicht zulassen. Es gibt übrigens Low-Power µCs mit LCD und RTC integriert (siehe EFM32 Serie bei Silabs). Deren STKs haben sogar ein CR2032 Batteriefach: https://www.silabs.com/products/mcu/lowpower/Pages/efm32-g8xx-stk.aspx
Jim Meba schrieb: > Die > damit erreichbaren µC Taktfrequenzen dürften 1 MHz I²C eher nicht > zulassen. Schön wäre es gewesen :/ Es wird allerdings kein LCD im herkömmlichen Sinne angesteuert, sondern ein weiteres I2C 'Gerät', welches dann eine Anzeige schaltet. Dessen SCL Frequenz geht maximal von 100-1000kHz, also wenn der uC die 400Mhz der RTC schafft, sollte auch die Anzeige gehen...
LiPoFeFaFu schrieb: > Dessen SCL Frequenz geht maximal von 100-1000kHz, also > wenn der uC die 400Mhz der RTC schafft, sollte auch die Anzeige gehen... Die Maximalgeschwindigkeit meines Autos beträgt laut Fahrzeugschein 178 km/h und laut GPS Messung 205 km/h. Wird mein Auto also unterhalb von 178 km/h nicht korrekt funktionieren? Deine Angabe "maximal von 100-1000kHz" ist Unsinn.
Jim Meba schrieb: > Das dürfte für ältere AVR und PIC zuwenig sein. Einen neueren nehmen. ;-) AVRs zumindest gibt es schon lange bis 1,8 V hinunter. Die zulässige Dauerlast von CR-Rundzellen wird aber gern mal überschätzt. Auch die Impulslast darf nicht sehr hoch sein, da sollte man einen dicken Elko oder KerKo mit an Bord haben.
Warum überhaupt ne separate RTC? Bei wenig benötigter Rechenleistung kann man den Controller direkt mit 32kHz takten. Bei höherer benötigter Rechenleistung kann man bei einigen Controllern einen asynchronen Timer mit einem Uhrenquarz takten. So spart man sich den Stromverbrauch des I2C-Interface und der zusätzlichen RTC. Ansonsten kann man mit diversen Stromsparmodi die Stromaufnahme erheblich drücken.
Flo schrieb: > Warum überhaupt ne separate RTC? Ja, warum? > Bei wenig benötigter Rechenleistung kann man den Controller direkt mit > 32kHz takten. Naja. Ich halte da nichts von. Aber... > Bei höherer benötigter Rechenleistung kann man bei einigen Controllern > einen asynchronen Timer mit einem Uhrenquarz takten. > So spart man sich den Stromverbrauch des I2C-Interface und der > zusätzlichen RTC. Atmega48..328 P(A). Aber da kannst du dir die Finger wundtippen, irgendwie kommt dieser Tip nie an. > Ansonsten kann man mit diversen Stromsparmodi die Stromaufnahme > erheblich drücken. 0,75µA mfg.
Magnus M. schrieb: > Deine Angabe "maximal von 100-1000kHz" ist Unsinn. Sry da kann ich dir jetzt nicht ganz folgen, laut Datenblatt sollte die SCL Frequenz bei mind 100kHz liegen, maximal bei 1000kHz.... Flo schrieb: > Warum überhaupt ne separate RTC? > Bei wenig benötigter Rechenleistung kann man den Controller direkt mit > 32kHz takten. > Bei höherer benötigter Rechenleistung kann man bei einigen Controllern > einen asynchronen Timer mit einem Uhrenquarz takten. > So spart man sich den Stromverbrauch des I2C-Interface und der > zusätzlichen RTC. Das ist eine gute Frage. Allerdings, was braucht weniger Strom im Schlaf und kann sich alles merken? Die Uhrzeit soll nur auf Knopfdruck angezeigt werden, den Rest kann der uC gerne pennen... Es ist mein erstes Projekt, dass so wenig wie möglich Strom verbrauchen soll wenn es nicht gebraucht wird. Jörg Wunsch schrieb: > Einen neueren nehmen. ;-) AVRs zumindest gibt es schon lange bis > 1,8 V hinunter. Hast du mir ein Beispiel ? :)
LiPoFeFaFu schrieb: > Jörg Wunsch schrieb: >> Einen neueren nehmen. ;-) AVRs zumindest gibt es schon lange bis >> 1,8 V hinunter. > > Hast du mir ein Beispiel ? :) Ich blätter gerade im Datenblatt vom ATtiny43U, falls du den meinst
Thomas Eckmann schrieb: > Atmega48..328 P(A). Aber da kannst du dir die Finger wundtippen, > irgendwie kommt dieser Tip nie an. Ohne Multiprozessorsystem kann das doch nichts taugen ;-)
LiPoFeFaFu schrieb: > Magnus M. schrieb: >> Deine Angabe "maximal von 100-1000kHz" ist Unsinn. > > Sry da kann ich dir jetzt nicht ganz folgen, laut Datenblatt sollte die > SCL Frequenz bei mind 100kHz liegen, maximal bei 1000kHz.... Na dann vergleiche mal Deine Aussage [Zitat] "laut Datenblatt sollte die SCL Frequenz bei mind 100kHz liegen, maximal bei 1000kHz" mit Deiner Aussage [Zitat] "maximal von 100-1000kHz" Fällt der Groschen?
Magnus M. schrieb: > LiPoFeFaFu schrieb: >> Magnus M. schrieb: >>> Deine Angabe "maximal von 100-1000kHz" ist Unsinn. >> >> Sry da kann ich dir jetzt nicht ganz folgen, laut Datenblatt sollte die >> SCL Frequenz bei mind 100kHz liegen, maximal bei 1000kHz.... > > Na dann vergleiche mal Deine Aussage [Zitat] > "laut Datenblatt sollte die SCL Frequenz bei mind 100kHz liegen, maximal > bei 1000kHz" > > mit Deiner Aussage [Zitat] > "maximal von 100-1000kHz" > > Fällt der Groschen? Ja sry, ich meinte den maximalen Minimalwert ;)
Was wäre denn das "weitere I2C-Gerät" das die Anzeige schaltet? Das sollte man auch noch wegoptimieren können, damit die Uhr aus einem einzigen Controller bestehen kann. :-)
LiPoFeFaFu schrieb: > Ich blätter gerade im Datenblatt vom ATtiny43U, falls du den meinst Naja, so ziemlich alle AVRs, die in den letzten 10 Jahren auf den Markt gekommen sind, sind 1,8-V-fähig (bis vor 5 Jahren teilweise mit explizit dafür ausgewiesenen Suffix-Buchstaben "V"). Es ist also im Wesentlichen eine Frage, was du da sonst noch dran hängen willst. Vielleicht willst du ja auch einen XmegaB nehmen und das LC-Display direkt ansteuern. ;-)
Flo schrieb: > Was wäre denn das "weitere I2C-Gerät" das die Anzeige schaltet? > Das sollte man auch noch wegoptimieren können, damit die Uhr aus einem > einzigen Controller bestehen kann. :-) Das ist leider nicht möglich ;)
Der EFM32ZG108F32 liest sich eigentlich nicht schlecht, hat anscheinend auch eine RTC eingebaut...allerdings habe ich noch nie mit Cortex gearbeitet
LiPoFeFaFu schrieb: > anscheinend auch eine RTC eingebaut Naja, so viel oder so wenig wie praktisch jeder andere Controller aus diesem Jahrtausend: den 32-kHz-Quarz musst du schon noch selbst draußen dranpappen, und ob die Uhr nun nur Sekunden oder Gregorianischen Kalender zählt, das entscheidet deine Software. Insofern unterscheidet sich das Teil kaum von einem gängigen AVR oder PIC. Sleepströme im Nanoamperebereich sind gut für die Marketingabteilung. Praktische Relevanz haben sie wenig, denn die beteiligten Batterien dominieren dann irgendwann die Ruhe-Verlustleistung.
Jörg Wunsch schrieb: > Insofern unterscheidet sich das Teil kaum von einem gängigen AVR oder > PIC. Genau deswegen bin ich ja hier :) ich suche einen uC, der i2C hat, mit 2-3V läuft und wenn er nicht gebraucht wird so wenig wie möglich verbraucht. Ob es jetzt ein PIC wird, ein AVR oder ein ARM, ist nicht relevant.
Wie dafür gemacht http://www.ti.com/lsds/ti/microcontrollers_16-bit_32-bit/msp/low_power_performance/msp430f5x_msp430f6x/overview.page
LiPoFeFaFu schrieb: > so wenig wie möglich verbraucht. Unsinnige Forderung. „So wenig, dass es nicht ins Gewicht fällt“ (weil die Batterie sich stärker selbst entlädt) wäre die sinnvolle Forderung, und das schaffen von den in Frage kommenden (kleineren) Controllern vermutlich 50 %.
Jörg Wunsch schrieb: > „So wenig, dass es nicht ins Gewicht fällt“ (weil die Batterie sich > stärker selbst entlädt) wäre die sinnvolle Forderung, und das schaffen > von den in Frage kommenden (kleineren) Controllern vermutlich 50 %. Na dann ist doch alles wunderbar :)
Nun besinn dich auf die Controllerfamilie, die du schon kennst, und löse dein Problem damit.
LiPoFeFaFu schrieb: > Versorgt wird die Uhr mit einer CR2032, sollte also mit 3V laufen. > I2C mit 400kHz bis 1Mhz sollte auch drin sein. > Möglichst kleine Bauform wäre auch nicht schlecht > > Als RTC kommt aller vorraussicht ein M41T62LC6F zum Einsatz, hat damit > schonmal jemand Erfahrung gemacht ? Etwas widersprüchliches Design. Wenn du nen µC an einer Batterie laufen lässt dann brauchst du doch keine zusätzliche Echtzeituhr. Einmal pro Sekunde die Zeit zu zählen und alle 24 Stunden Kalenderverwaltung macht jeder moderne Controller mit links. Du hast dann auch alles unter Software Kontrolle und ein Teil weniger zum rumärgern. Nicht mal ne I2C Schnittstelle brauchst du, das geht mit SoftI2C genau so gut. Stromsparend an einen Uhrenquartz geklemmt läuft das ganze mit genau der gleichen Präzision wie eine RTC. Wie sollte es auch anders sein? Wenn du unbedingt mehr speed willst schalte halt den internen Oszillator ein. Ist aber unnötiger Stromverbrauch. Die meisten I2C Chips haben statisches design und würden auch mit 10 Hz funktionieren. Meiner einer bekommt Pics mit 32kHz Schwinger auf unter 50nA im deep sleep. Die wachen dann einmal auf wenn der Counter voll ist, machen was Sie sollen und schnarchen weiter. Das geht bei allen anderen Herstellern wohl genau so.
Jörg Wunsch schrieb: > „So wenig, dass es nicht ins Gewicht fällt“ (weil die Batterie sich > stärker selbst entlädt) wäre die sinnvolle Forderung, und das schaffen > von den in Frage kommenden (kleineren) Controllern vermutlich 50 %. Nun laut diesem Datenblatt http://data.energizer.com/PDFs/cr2032.pdf beträgt die Selbstentladung ~1%/a bei 240mAh Kapazität. Das sind dann 2,4mAh per anno. Da Jahr hat 365x24 h = 8760h. Ergo ist der Selbstentladestrom 2,4mAh / 8760h = 0.00027397 mA = ca. 275nA. Meine 50nA erhöhen die "Selbstentladung" also um ca. 20%.
Dafür wiederum ist es interessant, wieviel man wirklich für den Betrieb an Energie benötigt. Da helfen die schillernden Sleepströme aus dem Datenblatt auch nicht. Viel zu rechnen ist bei so'ner Uhr auch nicht, also braucht man auch nicht weiter nach µA/MIPS oder sowas zu gucken. Entscheidend ist dann oft, wie lange das sekündliche Aufwachen selbst dauert. Das dümmste, was man tun könnte, wäre die Taktung des Controllers durch einen zweiten Quarz vornehmen zu lassen, denn diese brauchen ewige Zeit zum Anschwingen. Entweder (wie schon erwähnt) den Controller gleich vom 32-kHz-Quarz takten lassen (der muss ja ohnehin durchlaufen), oder (falls die Rechenleistung damit nicht ausreicht) von einem RC-Oszillator, der schnell im Anschwingen ist.
Jörg Wunsch schrieb: > Dafür wiederum ist es interessant, wieviel man wirklich für den > Betrieb an Energie benötigt Schon klar. Um das zu bewerten muss man aber den "Energieverbrauch" über einen größeren Zeitraum sehen. Die ganze Optimiererei nützt aber nichts wenn die Batterie mit den Fingern reingefummelt wird. Dann baut die Fett-Salz-Schweiss Mischung dem Strom einen Sonderweg. > Entweder (wie schon > erwähnt) den Controller gleich vom 32-kHz-Quarz takten lassen (der muss > ja ohnehin durchlaufen), Wenn ich dazu komme will ich den 32kHz Quarz nur noch zum kalibrieren des internen Schwingers verwenden und sonst einfach abschalten. Problem ist aber immer die Temperaturdrift. Quarze in der Armbanduhr haben ja einen super Quarzofen (den Träger des Teils außer bei Fieber ;-). Durch Temperaturmessung -> Abgleich sollte das eigentlich auch erreichbar sein. Hat das schon mal einer gemacht? > oder (falls die Rechenleistung damit nicht > ausreicht) von einem RC-Oszillator, der schnell im Anschwingen ist. Was aber bei Uhrenanwendungen keinen Sinn macht wg. der Drift. Pics können den internen Takt beliebig rauf und runter schalten. Da kann man die rechenintensiven Sachen mit 16Mhz und den Rest mit 32kHz beackern. Das wird bei anderen Herstellern nicht anders sein.
X4U schrieb: > Die ganze Optimiererei nützt aber nichts > wenn die Batterie mit den Fingern reingefummelt wird. Oder wenn Flussmittelreste allmählich Feuchtigkeit aufsammeln. > Wenn ich dazu komme will ich den 32kHz Quarz nur noch zum kalibrieren > des internen Schwingers verwenden und sonst einfach abschalten. Für eine Uhr lohnt das nicht, die Drift des RC-Oszillators ist da zu hoch, und die 32-kHz-Oszillatoren sind auf so geringe Betriebsströme getrimmt, dass das auch aus 'ner CR2032 eine Ewigkeit hält. >> oder (falls die Rechenleistung damit nicht >> ausreicht) von einem RC-Oszillator, der schnell im Anschwingen ist. > Was aber bei Uhrenanwendungen keinen Sinn macht wg. der Drift. Solange man die Uhr aus dem 32-kHz-Quarz betreibt und den schnellen RC-Takt nur für die Verarbeitung benutzt, ist das ja kein Thema. > Das wird bei anderen Herstellern nicht anders sein. So ist es, über clock prescaler, Umschaltung der Taktquelle (beim AVR ab Xmega auch zur Laufzeit) etc. Habe ich aber bislang nur selten gebraucht. Solange man alle Events per Interrupt bekommen kann, ist es meist effektiver, zwischendurch in einen mehr oder minder tiefen Schlaf zu fallen. Die Schalterei würde am ehesten dann lohnen, wenn man auf irgendein Ereignis pollen muss.
Ich versuche mal zu summieren ? Keine RTC -> da Stromfresser Irgendeinen uC ,der mit 1.8 bis 3V klarkommt, am besten mit 32khz (32,768),damit er selber die Uhrzeit rechnen kann, wobei aber die 32khz zu langsam für die I2C Verbindung ist, also noch einen RC-Oszillator, der beim Aufwachen mal kurz übernimmt um rechnen zu lasssen ?
Jörg Wunsch schrieb: > Für eine Uhr lohnt das nicht, Wohl wahr, für andere Anwendungen schon. Bei den Steuerungen die ich so baue halten die Li..-Zellen erfahrungsgemäß 10-15 Jahre und sind fest eingelötet (sind auch größer als CR2032). Da ist das schon interessant. > Oder wenn Flussmittelreste allmählich Feuchtigkeit aufsammeln. An der Batterie Flussmittelreste entfernen steht bei mir in der Checkliste. Die messe ich auch mit 4 Stellen hinterm Komma nach, da kann sehen ob sie isoliert ist oder eben nicht.
So ein Kinderkram ;-) Schaut mal da -> http://www.zoom.sjr-ulm.de/index.php?id=266 Im unteren Film sieht man bei ca. 5:20 eine Uhr mit einer 2032. Die 2032 sieht man nicht, ist auf der Rückseite. Der Controller ist ein PIC18F24J11 mit integriertem RTCC Modul. Die Anzeige besteht aus 12 zweifarbigen LEDs. Rot -> Stunden Grün -> Minuten (durch Blinken wird Minutengenau angezeigt) Orange -> Sekunden
LiPoFeFaFu schrieb: > Ich versuche mal zu summieren ? > Keine RTC -> da Stromfresser und unnötig. Die macht auch nichts anderes als interne Register weiter zählen. Den Kalender kannst du inkl. länderspezifischer Sommer/Winterzeit Schaltsekunden etc. in Software nachbilden. Da gibt es im Netz gute Beispiele. Falls die Politik dann auf die Idee kommt das ganze "neu zu gestalten" (wäre nicht das erste mal) ist es auch ohne Löterei anzupassen. > Irgendeinen uC ,der mit 1.8 bis 3V klarkommt, am besten mit 32khz > (32,768),damit er selber die Uhrzeit rechnen kann, Korrekt > wobei aber die 32khz > zu langsam für die I2C Verbindung ist, Einfach testen, sollte auch mit 32kHz laufen > also noch einen RC-Oszillator, > der beim Aufwachen mal kurz übernimmt um rechnen zu lasssen ? Brauchst du nicht,es sei den du willst mehr Batterien verkaufen. Fahr den internen Oszillator hoch und rechne damit. Leg in der Zeit den Quartz auf den internen Timer um die Zeit weiter zu zählen.
Volker SchK schrieb: > Im unteren Film sieht man bei ca. 5:20 eine Uhr mit einer 2032. > Die 2032 sieht man nicht, ist auf der Rückseite. Noch ein Film bei dem man die CR2032 auch nicht sieht, aber wenigstens die Halterung -> http://www.zoom.sjr-ulm.de/fileadmin/medien/feriencamp01/hightechuhr.html (so bei ~80% keine Ahnung welche Zeit ...)
:
Bearbeitet durch User
LiPoFeFaFu schrieb: > wobei aber die 32khz zu langsam für die I2C Verbindung ist Wieso das denn? Wer sagt das? I²C hat keine minimale Taktfrequenz. Die ergibt sich erst aus der zu übermittelnden Datenmenge und wie lange das jeweils brauchen darf.
Axel Schwenke schrieb: > Wieso das denn? Wer sagt das? Das Datenblatt des I2C Geräts ? Da steht nunmal 100khz als Minimum....
>Es ist mein erstes Projekt, dass so wenig wie möglich Strom verbrauchen
soll wenn es nicht gebraucht wird.
Lowpower ist ambitioes. Von der Wahl der Komponenten her muss man
aufpassen, von der Wahl der Programmstruktur her auch. Es benoetigt
viele Tricks um auf die per Spezifikation moeglichen uA
herunterzukommen. Das erste Mal wird's noch nicht so klappen. Ich wuerd
auch eine externe RTC verwenden. Die hat den Vorteil, noch weniger Strom
zu benoetigen, und sie laeuft waehrend dem Debuggen und reprogrammieren
weiter. Eine 1302 oder aehnlich ist mit 300nA spezifiziert.
Irgendwo benoetugt man dann noch einen spannungsregler, der mehr bringen
muss als als wenn man ihn weglaesst. Ich hab zB 1.8V Schaltregler, die
benoetigen 10uA Eigenverbrauch. Kann man das unterbieten, will man das
unterbieten ? Dann moechte man noch etwas Peripherie ansteuern koennen,
die aber mit 1.8V noch nicht laeuft, muss daher die Spannung kurz
erhoehen, usw...
:
Bearbeitet durch User
LiPoFeFaFu schrieb: > Das Datenblatt des I2C Geräts ? Da steht nunmal 100khz als Minimum.... Welches? Beim M41T62LC6F lese ich 0 bis 400kHz: http://www.st.com/web/en/resource/technical/document/datasheet/CD00019860.pdf Seite 34
qwerty schrieb: > Welches? Beim M41T62LC6F lese ich 0 bis 400kHz: > http://www.st.com/web/en/resource/technical/document/datasheet/CD00019860.pdf > Seite 34 Dieses, welches das Display ansteuert. Es wurde ja einvernehmlich geklärt das eine RTC aus dem Spiel ist. Passend zum Namen Jetzt Nicht schrieb: > Lowpower ist ambitioes. Von der Wahl der Komponenten her muss man > aufpassen, Deswegen keine RTC > von der Wahl der Programmstruktur her auch. Es benoetigt > viele Tricks um auf die per Spezifikation moeglichen uA > herunterzukommen. Das erste Mal wird's noch nicht so klappen. Ich wuerd > auch eine externe RTC verwenden. Die hat den Vorteil, noch weniger Strom > zu benoetigen, und sie laeuft waehrend dem Debuggen und reprogrammieren > weiter. Eine 1302 oder aehnlich ist mit 300nA spezifiziert Benötigt aber wieder ne I2C verbindung > > Irgendwo benoetugt man dann noch einen spannungsregler für was ? > muss als als wenn man ihn weglaesst. Ich hab zB 1.8V Schaltregler, die > benoetigen 10uA Eigenverbrauch. Kann man das unterbieten, will man das > unterbieten ? Dann moechte man noch etwas Peripherie ansteuern koennen, > die aber mit 1.8V noch nicht laeuft, muss daher die Spannung kurz > erhoehen, usw... Muss man nicht, jedenfalls nicht in meinem Fall.
LiPoFeFaFu schrieb: > Das Datenblatt des I2C Geräts ? Da steht nunmal 100khz als Minimum.. Dann drehst du halt den internen Quarz hoch wenn du auf IC2 schreibst. Jetzt Nicht schrieb: > Irgendwo benoetugt man dann noch einen spannungsregler Bei einer Batterie mit Umax=3V?
qwerty schrieb: > Welcher uC hat so etwas? Ziehe eine Ereigniskarte, ersetze Quarz mit interner Oszillator, gehe nicht über los und ziehe keine 2000 ein.
LiPoFeFaFu schrieb: > Das Datenblatt des I2C Geräts ? Da steht nunmal 100khz als Minimum.... Das kann nicht sein. Entweder irgendeine Minimalfrequenz oder I2C. Der I2C-Standard sagt, daß der Bus beliebig langsam sein kann. Geht das nicht, ist es nicht I2C. MfG Klaus
Klaus schrieb: > Das kann nicht sein. Entweder irgendeine Minimalfrequenz oder I2C. Der > I2C-Standard sagt, daß der Bus beliebig langsam sein kann. Geht das > nicht, ist es nicht I2C. Dann nenne ihn doch I2C mit der Ausnahme von 100 kHz Minimum Takt. Es wird wohl nicht grundlos im Datenblatt stehen.
LiPoFeFaFu schrieb: > Möglichst kleine Bauform wäre auch nicht schlecht Ist kein AVR und kein PIC, aber was hältst Du von dem EZ430-Chronos? http://processors.wiki.ti.com/index.php/EZ430-Chronos
X4U schrieb: > Dann nenne ihn doch I2C mit der Ausnahme von 100 kHz Minimum Takt. Es > wird wohl nicht grundlos im Datenblatt stehen. Das du das so nennen kannst, ist klar. Das aber beides in einem Datenblatt geschrieben ist, ohne das da NXP die Veröffentlichung untersagt hat, scheint mir fraglich. Selbst Atmel muß TWI schreiben. Steht das also wirklich da drin? LiPoFeFaFu schrieb: > Es wird allerdings kein LCD im herkömmlichen > Sinne angesteuert, sondern ein weiteres I2C 'Gerät', welches dann eine > Anzeige schaltet. Ich kann in diesem Thread keinen Link auf das Datenblatt von diesem 'Gerät' finden, daher gehe ich davon aus, daß die 100kHz einfach Unsinn sind. MfG Klaus
Klaus schrieb: > Steht das also wirklich da drin? Nein. In einer Tabelle mit der Überschrift 'I2C Timing Characteristics' steht als erstes 'fSCL - SCL Frequenz - min 100 kHz - max 1000kHz' da geh ich einfach mal davon aus, das SCL zwischen diesen beiden Werten übertragen können sollte. Klaus schrieb: > Ich kann in diesem Thread keinen Link auf das Datenblatt von diesem > 'Gerät' finden, daher gehe ich davon aus, daß die 100kHz einfach Unsinn > sind. Deswegen nenne ich es immer nur 'Gerät'. Ich darf es nicht hier posten.
Angehängte Dateien:
-
Selection_012.png
6,6 KB
So stehts in der I2C Spec. Und wenn sich das 'Gerät' schon daran nicht hält, würde ich den Rest des I2C Protokolls auch in Frage stellen. MfG Klaus
LiPoFeFaFu schrieb: > Axel Schwenke schrieb: >> Wieso das denn? Wer sagt das? > > Das Datenblatt des I2C Geräts ? Da steht nunmal 100khz als Minimum.... Zeigen! Ich glaube bis auf weiteres erstmal nur, daß du kein Datenblatt lesen kannst.
Naja, dann kannst du deinen Controller halt nicht selbst mit 32 kHz takten. Ist aber nicht wirklich ein Beinbruch. „I²C“ hätten sie dann besser nicht dran schreiben sollen. ;-)
Weshalb man einen 1.8V Spannungsregler braucht ? Na, um den doppelten Strom aus der Batterie zu bekommen, ohne zu verheizen.
Jörg Wunsch schrieb: > Naja, dann kannst du deinen Controller halt nicht selbst mit 32 kHz > takten. Ist aber nicht wirklich ein Beinbruch. „I²C“ hätten sie dann > besser nicht dran schreiben sollen. ;-) dafür wird dann halt der interne genommen... Flo schrieb: > Soll das "Gerät" auch mit der CR2032 versorgt werden? > Was braucht das "Gerät"? ja
Hmmm, darfst du uns verraten, für wen dieses Gerät ist? Für das Militär? Für die Geheimdienste, für das Finanzamt, für die Content-Maffia...?
Noch einer schrieb: > Hmmm, darfst du uns verraten, für wen dieses Gerät ist? Für das Militär? > Für die Geheimdienste, für das Finanzamt, für die Content-Maffia...? Vieeeeel schlimmer, für den Verbraucher O.o
Bonzzo schrieb: > Weshalb man einen 1.8V Spannungsregler braucht ? Na, um den doppelten > Strom aus der Batterie zu bekommen, ohne zu verheizen Wo ein Wille, da ein Holzweg ;-). Wenn ich z.B die Grafiken dieser Seite: http://www.low-powerdesign.com/121312-article-extending-battery-life.htm richtig interpretiere dann saugst du aus einer CR2032 zwischen 1,8 und 1,6 V immerhin noch ca. 1mAh. Danach ist FEP Fundamental End Point . Was wohl mit rien ne va plus übersetzt werden kann. Oder auch "Wie Flasche leer". Ob sich dafür dein Spannungsregler lohnt? Das deckt sich auch mit den Datenblättern die ich kenne. Da ist bei 1,8V ebenso Ende im Gelände. Impulslasten vermeiden ist wichtiger. Die gesamte Kapazität gibt Sie nur her wenn die Schaltung nicht zu gierig ist (Imax 500µA). LiPoFeFaFu schrieb: > Vieeeeel schlimmer, für den Verbraucher O.o Du armer Kerl.
Thread beobachten
Seitenaufteilung abschaltenBitte 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.