Hallo Forum Bin neu hier und möchte mein altes Hobby nach 20 Jahren wieder aufnehmen. Habe damals 8051 in Assambler programmiert und auch Grundkenntnisse in C gesammelt. Nun möchte ich mich an ein neues Projekt wagen. Das geplante Gerät sollte batteriebetrieben werden und darum einen möglichst kleinen Strombedarf aufweisen, wobei die benötigte Rechenleistung gering ist. Gemäss Recherchen im Internet, bieten so gut wie alle Hersteller auch lowpower Varianten ihrer uC's an. Energymicro behauptet sogar, dass ihr ARM über alles gesehen weniger Energie benötigt als ein 8 Biter, da er länger im Sleepmodus verweilen kann. Nun meine Frage ans Forum: Hat jemand schon Erfahrungen mit lowpower Anwendungen gemacht und welcher uC wurde dabei verwendet? Ich lese seit ein paar Monaten hin und wieder im Forum mit und habe festgestellt das Fragen mit "welcher uC" regelmässig zu ausgedehnten Disputen führen. Dieser Beitrag ist ernst gemeint und ich will keinen Streit anzetteln. Dank und Gruss Thomas
Ich habe eine Anwendung, bei der ein PIC12F1822 alle 20 Minuten aus SLEEP aufwacht, etwas misst und wieder weiterschläft. Läuft mit CR2032 >1 Jahr. Das können aber sehr viele moderne µC, auch AVR.
P.S. mit der LF-Version vom 1822 habe ich eher schlechte Erfahrungen gemacht, lief nicht stabil.
@ Thomas Gemperle (perle68) >Hat jemand schon Erfahrungen mit lowpower Anwendungen gemacht und >welcher uC wurde dabei verwendet? Viele Leute. Prinzipiell gehen alle halbwegs aktuellen Mikrocontroller. Ob nur PIC, AVR, MSP430 oder auch einer der vielen ARM ist egal. Die kommen je nach Sleep Mode alle auf 1µA und weniger, wenn es denn sein muss.
> Nun meine Frage ans Forum: > Hat jemand schon Erfahrungen mit lowpower Anwendungen gemacht und > welcher uC wurde dabei verwendet? > Hallo! Ich habe beruflich immer wieder mit Low Power zu tun. Der Klassiker wäre da wohl der MSP430, der schon recht gute Werte erreicht. Die neueren MSP430 FRAM-Prozessoren sind allerdings problematisch im LPM-Design. Silabs hat in den letzten Jahren auch ein gutes Portfolio in Low-Power aufgebaut. Dazu gehören auch die 8051-Derivate (bspw die c8051f91x / 96x könntest du dir da angucken) STM8L geht auch bedingt. Bei denen ist es Pflicht einen externen Quarz dran zu packen, sonst kommst du nur "auf 2 MHz runter" (8 MHz, Prescaler 4) EnergyMicro (mittlerweile gekauft von Silabs) wäre jetzt meine erste Wahl, wenn es um 32 Bit geht, wobei ich die in der Praxis noch zu wenig verwendet habe. Bei 32 Bit verwende ich allerdings momentan STM32L1 für ein neues Projekt.
Kauf dir doch ein paar PICs auf ebay z.B. 16LF1709 16F1703 24F04KL101 Die koennen alle Low Power, und haben internen Oszillator. Der kann oft auf 500 KHz eingestellt werden, dann mit Sleep die CPU stilllegen, und WDT (Watch Dog Timer) zum automatischen Aufwecken verwenden. Moderne PIC koennen so programmiert werden dass der WDT nur alle paar Sekunden aktiviert wird. Es gibt auch spezielle Ultra Low Power PICs. Mit externem Quartz brauchst du immer einige 10 bis 100uA. Allerdings kleine PICs sind auch im MHz Bereich noch sparsam. Was ist denn dein Powerbudget?
Das war vor 5 Jahren: https://www.youtube.com/watch?v=nHc2tbxcDRA Vergleich PIC nanoWatt XLP mit MSP430: https://www.youtube.com/watch?v=NifzpSOlY2k Gruß John
Phantomix Ximotnahp schrieb: > STM8L geht auch bedingt. Bei denen ist es Pflicht einen externen Quarz > dran zu packen, sonst kommst du nur "auf 2 MHz runter" (8 MHz, Prescaler > 4) > > EnergyMicro (mittlerweile gekauft von Silabs) wäre jetzt meine erste > Wahl, wenn es um 32 Bit geht, wobei ich die in der Praxis noch zu wenig > verwendet habe. > Bei 32 Bit verwende ich allerdings momentan STM32L1 für ein neues > Projekt. wo siehst du das mit dem STM8L? laut DS geht scheinbar sogar 125KHz Hast du dir die neuen STM32L0 angesehen?ich wollte diese nutzen, leider ist darin weder adc noch dac funktionsfähig bei unter 1.8V, ich bin folglich beim xmega geblieben. hab mich schon gefreut und ist nix.
Wenn du "den niedrigsten Verbrauch" ich aus sportlichem Ehrgeiz anstrebt, dann sind MSP430 und Co. Richtig. Willst du einfach ein paar Monate mit ner Knopfzelle auskommen, dann bist du bei AVRs richtig. In diesem forum ist die größte userbase nunmal AVR (nicht umsonst ist das Logo der site mit "avr" bschriftet). Du bekommst also am besten Unterstützung.
"AVR" heißt hier "Atom Versuchs Reaktor" und hat nichts mit dem Atmel Prozessor zu tun.
> Das geplante Gerät sollte batteriebetrieben werden und darum einen > möglichst kleinen Strombedarf aufweisen, wobei die benötigte > Rechenleistung gering ist. Dann muesstest du vermutlich irgendeinen maskenprogrammierten 4Bit Controller verwenden wie er in deiner Armbanduhr verwendet wird. :-) Welcher der vielen Controller (btw: die Renesas RL78 wurden noch nicht genannt, 46uA/Mhz) aber in deiner Anwendung am laengsten haelt, laesst sich nicht so einfach sagen. Es haengt naemlich sehr davon ab welche eingebauten Features gut zu deiner Anwendung passen. Ausserdem braucht man sowohl bei Systemdesign, Softwareentwicklung und Hardwareentwicklung etwas spezielle Erfahrung wenn du wirklich das Maximum rausholen willst. Eigentlich interessant das da noch niemand ein Buch drueber geschrieben hat das speziell darauf eingeht.... Olaf
Bei sehr vielen Microcontrollern lässt sich die Leistungsaufnahme des CPU-Kerns sehr weit absenken, was dann auch vom Marketing des Hersteller gut ausgenutzt wird. Das, was einem aber ganz schnell einen Strich durch die Rechnung machen kann, sind einige wichtige Peripherieblöcke, z.B. Watchdogtimer oder Brown-Out-Detektor, letzteres vor allem auch bei vielen Attiny. Dafür ist der Vorteil vieler AVR, dass man sie noch bis 6V ohne zusätzlichen Spannungsregler betreiben kann. Ansonsten kommen nämlich dafür auch noch gerne ein paar Mikroampere zusammen. Gerade bei vielen Cortex-M0 hat man nur einen sehr engen Versorgungsspannungsbereich, was sich wiederum nicht mit einem Batteriebetrieb verträgt.
Max D. schrieb: > Wenn du "den niedrigsten Verbrauch" ich aus sportlichem Ehrgeiz > anstrebt, dann sind MSP430 und Co. Richtig. Hast Du das von mir verlinkte Video gesehen? Andreas Schweigstill schrieb: > Das, was einem aber ganz schnell einen Strich durch > die Rechnung machen kann, sind einige wichtige Peripherieblöcke, z.B. > Watchdogtimer oder Brown-Out-Detektor, letzteres vor allem auch bei > vielen Attiny. Aus den Video: PIC-XLP MSP430 Sleep 65nA nicht verfügbar Deep Sleep 20nA nicht verfügbar Deep Sleep +BOR 50nA 100nA Deep Speep +WDT 300nA 300nA Deep Sleep +RTCC 450nA 1200nA Die 'LF'-PICs können im allgemeinen nur mit bis zu 3,6V betrieben werden. Die Werte im Video beziehen sich auf den Betrieb mit 1,8V. Bei höherer Betriebsspannung ist auch die Stromaufnahme entsprechend höher. Und ja, falls ein Spannungsregler erforderlich ist, braucht dieser gleiche ein vielfaches des Controllers. Gruß John
Lowpower ist mehr als nur der Controller. Das Ganze drum herum ist mindestens so wichtig. Man kann ueberall vieles falsch machen. Ein 1 Mega pullup @ 3V ... oops 3uA verschleudert ohne viel Nutzen.
John schrieb: > Und ja, falls ein Spannungsregler erforderlich ist, braucht dieser > gleiche ein vielfaches des Controllers. Bei Ub<=5.5V würde ein 'F' PIC, ber bis 5.5V geht, vllt. weniger verbrauchen als ein 'LF' + Regler.
Hallo, > Nun möchte ich mich an ein neues Projekt wagen. Das geplante Gerät > sollte batteriebetrieben werden und darum einen möglichst kleinen > Strombedarf aufweisen, wobei die benötigte Rechenleistung gering ist. Suche dir einen beliebigen Mikrocontroller aus. Mit einem 8051-Hintergrund dürfte dir der Einstieg bei AVR oder PIC wesentlich leichter fallen, als bei ARM. Letztere sind wesentlich komplexer, dafür auch leistungsfähiger. Du kannst natürlich auch MSP430 oder Renesas benutzen, aber da wird dir hier weniger geholfen. > Hat jemand schon Erfahrungen mit lowpower Anwendungen gemacht und > welcher uC wurde dabei verwendet? Ob ein Controller nun 40uA, 80uA oder 2000uA im Sleep zieht, dürfte im Vergleich mit dem Rest der Schaltung egal sein. Als (Wieder)Einsteiger dürften dir sowieso erstmal andere Probleme auf die Füße fallen als ein paar verschenkte Stunden Batterielaufzeit. :-) > Ich lese seit ein paar Monaten hin und wieder im Forum mit und habe > festgestellt das Fragen mit "welcher uC" regelmässig zu ausgedehnten > Disputen führen. Dieser Beitrag ist ernst gemeint und ich will keinen > Streit anzetteln. Diesen Disclaimer schreiben auch alle anderen unter ihre Beiträge. Den Streit gibt es trotzdem. Gruß, Svenska
Max D. schrieb: > In > diesem forum ist die größte userbase nunmal AVR (nicht umsonst ist das > Logo der site mit "avr" bschriftet). Das nenne ich mal ein schlagkräftiges Argument. Denn die größte userbase bei Autos gibt es zum Golf III. Also sollte jeder einen Golf III kaufen. ;-P
Augenklappenöffner schrieb: > Also sollte > jeder einen Golf III kaufen. ;-P Wenn er am Golf III rumschrauben will obwohl er kaum Erfahrung hat, dann könnte es durchaus sinnvoll sein sich daran zu orientieren. Nicht umsonst gibt es http://www.mikrocontroller.net/articles/AVR-GCC-Tutorial auf der Mainpage verlinkt.
Max D. schrieb: > Wenn er am Golf III rumschrauben will obwohl er kaum Erfahrung hat, dann > könnte es durchaus sinnvoll sein sich daran zu orientieren. ??? Es geht um den Einstieg und nicht genau das Teil! Warum sollte ein Einsteiger auf alte Kamelle setzen?
Aller Anfang ist schwer. Wenn er dann also mit dem proggen loslegen will, dann ist es sinnvoll auf eine Platform zu setzen bei der ihm möglichst viele Menschen helfen können wenn er auf Probleme stößt. Die Analogie mit dem Golf 3 kam von dir und wurde von mir nur aufgegriffen. Einen AVR würde ich jetzt auch nicht als "olle Kammelle" bezeichnen. Einige Typen haben zwar schon viele jahre auf dem Buckel (die AT90er z.b.) aber es gibt ja auch neue (XMegas). Wie sinnvoll die neuen sind sei mal dahingestellt, bei der Anzahl an Bugs in dem Xmegas sind die noch keine Freude. Und bei einem Auto ist zum schrauben (schrauben als analogie zum programmieren) eine "olle Kammelle" oft besser geeignet. Die ganzen neuen Autos sind verklebt, verdongelt und verschweißt.
@John (Gast) > PIC-XLP MSP430 >Sleep 65nA nicht verfügbar >Deep Sleep 20nA nicht verfügbar >Deep Sleep +BOR 50nA 100nA >Deep Speep +WDT 300nA 300nA >Deep Sleep +RTCC 450nA 1200nA Alles schön und gut. Aber genau DAS brauchen die meisten (Hobby)projekte brauchen solches extremes Stromsparen keine Sekunde. Alles unter 1µA ist mehr als ausreichend. Und das können die meisten uC.
Max D. schrieb: > wenn er auf Probleme stößt. Oder man nimmt etwas, bei dem die bösartigen Probleme nicht entstehen. Hast du schon mal einen MSP430 verfused? Warum wohl nicht? ;-P
kopfkratz Ja was ist denn nun die eigentliche Anforderung ? Das der µC regelmäßig aufwacht und Daten kurzfristig verarbeitet, z.B. durch IRQ o.ä. ? Oder soll er ständig Daten verarbeiten also niemals schlafen gehen ? Welche Daten sollen wie und wann verarbeitet werden ? Welche Stromquelle soll verwendet werden und wie lange soll das ganze laufen ? Dann kann auch gezielt gesucht werden ;-)
Augenklappenöffner schrieb: > Hast du schon mal einen MSP430 verfused? Einen PIC hat auch noch niemand verfused...
Max H. schrieb: > Einen PIC hat auch noch niemand verfused Aber du wirbst für AVR. Dich soll einer verstehen!?
Augenklappenöffner schrieb: > Aber du wirbst für AVR Darf ich Fragen in welchem Post? Du wirst wahrscheinlich im gesamten Forum keinen Post finden, in dem ich für AVR werbe. Kann es sein, dass du den Unterschied zwischen "D." und "H." nicht kennst?
:
Bearbeitet durch User
Max H. schrieb: > Kann es sein, dass du den Unterschied zwischen "D." und "H." nicht > kennst? Stimmt, da habe ich euch durcheinander gewürfelt.
Augenklappenöffner schrieb: > Max D. schrieb: > wenn er auf Probleme stößt. > > Oder man nimmt etwas, bei dem die bösartigen Probleme nicht entstehen. > Hast du schon mal einen MSP430 verfused? Warum wohl nicht? ;-P Bloß weil man ihn nicht verfusen kann ist ein yC nicht automatisch Störungsfrei. Es gibt genug anderes zum falsch machen, da braucht man keine fuses. Das ist keine Beleidigung gegen den to, sondern eine Tatsache. Wenn etwas sofort fehlerlos ist, dann hat man nur welche übersehen ^^. Selbst Profis machen Anfängerfehler, siehe heartbleed.
John schrieb: > Hast Du das von mir verlinkte Video gesehen? > > Andreas Schweigstill schrieb: >> Das, was einem aber ganz schnell einen Strich durch >> die Rechnung machen kann, sind einige wichtige Peripherieblöcke, z.B. >> Watchdogtimer oder Brown-Out-Detektor, letzteres vor allem auch bei >> vielen Attiny. > > Aus den Video: > PIC-XLP MSP430 > Sleep 65nA nicht verfügbar > Deep Sleep 20nA nicht verfügbar > Deep Sleep +BOR 50nA 100nA > Deep Speep +WDT 300nA 300nA > Deep Sleep +RTCC 450nA 1200nA > > Die 'LF'-PICs können im allgemeinen nur mit bis zu 3,6V betrieben > werden. Die Werte im Video beziehen sich auf den Betrieb mit 1,8V. Bei > höherer Betriebsspannung ist auch die Stromaufnahme entsprechend höher. > Und ja, falls ein Spannungsregler erforderlich ist, braucht dieser > gleiche ein vielfaches des Controllers. > > Gruß > John Da geht Microchip aber sehr großzügig mit der Wahrheit um. http://www.ti.com/general/docs/lit/getliterature.tsp?baseLiteratureNumber=slay015&fileType=pdf Wenn es um ultra-niedrigen Verbrauch geht, kommt es vor allem darauf an, wie schnell der µC aus dem Schlafzustand aufwacht. Wenn diese Information nicht auf der ersten Seite des Datenblattes auftaucht, würde ich einen großen Bogen um den µC machen. Also keinen PIC XLP und ganz bestimmt keinen AVR. Wenn keine größeren Berechnungen auszuführen sind, ist der MSP430 keine schlechte Wahl, ansonsten würde ich eher auf einen ARM setzen.
Ist das nur Zufall, dass bei beiden Dokumenten/Tests der µC des Verfassers besser dasteht?
Also eine Leuchtdiode liefert schon fast 1 uA be Beleuchtung. Kann so ein uC dann mit ein paar Billig Leuchtdioden als Stromquelle betrieben werden?
Takao K. schrieb: > Kann so ein uC dann mit ein paar Billig Leuchtdioden als Stromquelle > betrieben werden? Das Problem dabei dürfte die Spannung sein. Das ist allerdings eininteressantes Thema. Google mal nach Energy Harvesting ist teilweise echt lustig was die sich einfallen lassen für ein paar uWatt.
Thomas schrieb: > Also keinen PIC XLP und ganz > bestimmt keinen AVR. Wenn keine größeren Berechnungen auszuführen sind, > ist der MSP430 keine schlechte Wahl, ansonsten würde ich eher auf einen > ARM setzen. Der TO hat mit 8051 Erfahrung und will jetzt wieder in µCs einsteigen. Er hat nicht vor als Erstprojekt eine Satellitensteuerung zu bauen, die mit Solarzellen auch noch jenseits des Neptuns genügend Strom für den µC hat. Wie wärs wenn alle Fanboys einfach mal auf dem Boden bleiben.
Die Anwendung, die ich hatte, sollte mit <10µW auskommen. Da blieb nur der EFM32LGxxx übrig. Verschiedene Messungen und serielle Kommunikation inclusive. Ohne Batterie, nur mit Supercap. War aber mit einigen Tricks, auch in Hardware, verbunden. Die Einarbeitungszeit gegenüber einem AVR ist aber deutlich länger. Die Entwicklertools sind alle frei (z.B.: IAR 32kByte-Free-Version), einzig ein (kleines) Development-Kit braucht man um die Programme zu laden, zum debuggen und zum Stromverbrauch messen. Da reicht auch ein EFM32-TinyGecko-Kit für ca. 70,-€. Blackbird
Udo Schmitt schrieb: > Thomas schrieb: >> Also keinen PIC XLP und ganz >> bestimmt keinen AVR. Wenn keine größeren Berechnungen auszuführen sind, >> ist der MSP430 keine schlechte Wahl, ansonsten würde ich eher auf einen >> ARM setzen. > > Der TO hat mit 8051 Erfahrung und will jetzt wieder in µCs einsteigen. > Er hat nicht vor als Erstprojekt eine Satellitensteuerung zu bauen, die > mit Solarzellen auch noch jenseits des Neptuns genügend Strom für den µC > hat. > > Wie wärs wenn alle Fanboys einfach mal auf dem Boden bleiben. Soso, man ist also jetzt ein Fanboy, wenn man erklärt, warum AVRs ungeeignet für low-power Anwendungen sind. Da fragt man sich, wer hier der wirkliche Fanboy ist.
Liest der TE noch mit, oder hat ihn der Flamewar-Pulverdampf verschreckt? Was soll die Schaltung denn tun? Was aktiviert sie? Das sehe ich als den wesentlichen Punkt an, bevor hier Empfehlungen für den ein oder anderen uC gegeben werden können. Nur ein Beispiel: Es kostet recht "viel" Energie, einen Oszillator am Laufen zu halten. Wenn der uC den abschalten darf und immer durch ein äußeres Ereignis geweckt wird (z.B. durch einen Tastendruck statt regelmäßig durch einen internen Timer), dann hatte ich schon mit einem nicht gerade für Low Power beworbenen ATtiny25 eine Ruhestromaufname von 70 nA (richtig gelesen: Nanoampere). Um da hin zu kommen muß man einiges beachten, um nicht aus Versehen was eingeschaltet zu lassen was den Strom um eine Größenordnung erhöht: Analogfunktionen und Brownout müssen aus sein, damit die interne Bandgap-Diode stromlos sein kann. Die nicht benötigten Eingänge kann man abschalten, weil auch die Logik dahinter Strom braucht. Will sagen: so ganz einfach ist es nicht... Jörg
Udo Schmitt schrieb: > Der TO hat mit 8051 Erfahrung und will jetzt wieder in µCs einsteigen. Hast ja Recht im Prinzip. Ich sag mal so: 8051 vor 20 Jahren heißt für mich: Erfahrung im Assembler. Der µC ist zwar steinalt, aber wer sich nicht scheut, kleinere Projekte in Assembler durchzuziehen und nicht als allererstes nach C und Eclipse schreit, hat gute Karten auch bei anderen kleinen Achtbittern und da fällt mir zu allererst PIC16 ein, getaktet mit einem 32 kHz Uhrenquarz. Diese Kombination ist durchaus batterietauglich, kann problemlos in ASM programiert werden und ist für jemanden, der sich in 8051 asm auskennt, keine echte Hürde. Natürlich gibt es auch 8951-Nachfahren, teilweise mit Taktfrequenzen bis 80 MHz usw. Aber erstens nicht im üblichen Bastel-Handel und zweitens nicht für stromsparende Sachen mit relativ wenig Rechenbedarf. W.S.
Hallo Forum Erst mal, danke für die Tip's! Mein Fazit: Der uC Typ ist nicht so entscheidend. Ebenso wichtig ist der Rest der Schaltung bezüglich des Stromverbrauchs. Die Erhältlichkeit der Bauteile in Kleinmengen muss beachtet werden. Ist eine freie oder günstige Entwicklungsumgebung erhältlich. Aus meinem Projekt sollte einmal eine Uhr mit LCD Display hervorgehen. Der uC muss einmal pro Sekunde die Uhrzeit aus der in- oder externen RTC auslesen und das Display aktualisieren. Das ganze sollte mit einer Litiumknopfzelle betrieben werden. Dank und Gruss Thomas
Hallo, ich habe ein paar Sensorträger mit RFM12 gebaut (Außentemperatur und Feuchte). Verwendet habe ich folgenden: PIC24FJ128GC006 Ein Fluke 89III zeigt 2,1µA im Deep Sleep an. Das ist aber die Summe aus LDO und PIC sowie die Leckströme der FET. Das Ding wacht alle 30s auf, misst und legt sich wieder schlafen. Ab und zu wird das hineingefunkt. Eigentlich geht jeder PIC mit "NanoWatt", sowie entsprechendes von anderen Herstellern. (TI soll gut sein) Der von mir genannte PIC hat den großen Vorteil das er Retention deep sleep hat - man muss nicht neu booten beim aufwachen - das Programm läuft weiter wo man aufgehört hat. Vorteilhaft, wenn man wie ich einen Bootloader verwendet. Viel wichtiger als der µC ist aber die Peripherie. OPV z.B. gehen gar nicht (da sind gleich mal ein paar 100µA zusammen), daher schalte ich jeden einzelnen Block mittels PFET weg. Der Spannungsregler ist sehr kritisch, man bekommt kaum welche die darüf wirklich taugen. Eine kenne ich aber: TPS70933DBVR
Thomas Gemperle schrieb: > Aus meinem Projekt sollte einmal eine Uhr mit LCD Display hervorgehen. Es gibt PIC16/18 mit integriertem LCD-Segment Treiber: z.B. den PIC16LF(1)903: nanoWatt XLP und bis zu 72 LCD Segmente
:
Bearbeitet durch User
Thomas Gemperle schrieb: > Der uC Typ ist nicht so entscheidend. So ist es. Die Unterschiede sind so gering, daß sie sowieso nur im Extrembereich relevant werden und gegenüber der Peripherie sind sie praktisch immer irrelevant. > Ebenso wichtig ist der Rest der Schaltung bezüglich des Stromverbrauchs. Meistens sogar viel wichtiger. > Aus meinem Projekt sollte einmal eine Uhr mit LCD Display hervorgehen. > Der uC muss einmal pro Sekunde die Uhrzeit aus der in- oder externen RTC > auslesen und das Display aktualisieren. Moment mal. Was ist das denn für ein Display? Entweder eins mit eigener Elektronik, in diesem Fall kannst du davon ausgehen, daß die Stromaufnahme des µC im Vergleich dazu sowieso völlig unwichtig wird oder es ist ein sozusagen "nacktes" LC-Display. Dann ist's aber nix mit dem von dir beschriebenen Funktionsprinzip von wegen: "Aktualisieren und Pennen". Damit wird das Display nämlich sehr schnell zu Sondermüll. Da heißt es vielmehr: regelmäßig aufwachen und Pin-Polaritäten tauschen. Da wird dann i.d.R. sehr wichtig, wie schnell das Aufwachen aus dem "taktlosen" Zustand möglich ist, denn in dieser Aufwachphase wird das Ding u.U. sehr viel mehr Zeit verbringen als beim Rechnen für die (sehr viel selteneren) Aktualisierungen des Displayinhalts. Diese Eigenschaft ist etwas, was die Marktschreier auch sehr gerne verschweigen, bzw. tief im Datenblatt verstecken. Kann aber sehr wesentlich sein. Eben weil das so ist, gibt es oft spezialisierte Varianten der µC extra für die Ansteuerung solcher Displays, die diese Sache abhandeln können, ohne daß der eigentliche Rechenkern dafür aufwachen muß.
> Der uC Typ ist nicht so entscheidend. Das ist in deinem Fall dann leider nicht so. > Aus meinem Projekt sollte einmal eine Uhr mit LCD Display hervorgehen. Dann solltest du einen Mikrocontroller nehmen der in der Lage ist dumme Glaser anzusteuern. Ein normale LCD mit Controller braucht soviel Strom das der Microcontroller da nicht mehr so entscheidend ist. Olaf
Thomas Gemperle schrieb: > Ist eine freie oder günstige Entwicklungsumgebung erhältlich. Für PICs gibt es die MPLAB X IDE und dem XC8-Compiler kostenlos, auch für kommerziellen Einsatz. Bei XC8 muss man bei der kostenlosen Version auf Teile der Optimierung verzichten. Olaf schrieb: > Dann solltest du einen Mikrocontroller nehmen der in der Lage ist dumme > Glaser anzusteuern. Der oben genannte PIC16 wäre z.B. so einer. Es gibt auch PIC18 und PIC24 mit LCD-Treiber und eingebautem RTCC, aber leider nur mit >=64 Pins.
:
Bearbeitet durch User
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.