Hallo zusammen, ich suche für ein Projekt einen Mikrocontroller. Dieser sollte haben: 1xSPI,1xI2C, 4xIO-Pin, gut benutzbare Sleep Modes. Ich bin noch relativ neu in der Materie, und habe bisher nur mit Arduino, einem Standalone atmega1284p und Raspberry Pi Pico gearbeitet. Ich hätte noch einen Atmega1284p hier, allerdings wären die vielen IO Pins für dieses Projekt verschwendet, da ich ja nur eine Hand voll brauche. Es geht darum, Daten zu sammeln (I2C) und diese nach einer bestimmten Zeit über LoRa(SPI) wegzuschicken. Der Mikrocontroller ist also die meiste Zeit in einem Low-Power Mode Vielen Dank schon mal für Eure Vorschläge
Für Low-Power geht z.B. die MSP430-Serie von TI ganz gut. Ansonsten STM32L0, die dürften aber schwerer zu bekommen sein.
Ansonsten bleib bei AVR, wenn du da eh schon Erfahrung mit hast. Zum entwickeln bleib bei deinem Atmega, wenn du dann Abschätzen kannst, wieviel Flash, Ram usw. du brauchst, nimmst du den kleinsten/billigsten passenden Attiny (der auch verfügbar ist)...
Sebastian R. schrieb: > Für Low-Power geht z.B. die MSP430-Serie von TI ganz gut. Ansonsten > STM32L0, die dürften aber schwerer zu bekommen sein. Mit den MSP430ern hatte ich nie zu tun aber meine leidvolle Erfahrung der letzten 24 Monate lässt in mir die Frage aufkommen, ob es irgend ein TI-Bauteil gibt, das momentan erhältlich ist. Wir haben damit gerade so unsere Probleme...
Εrnst B. schrieb: > Ansonsten bleib bei AVR, wenn du da eh schon Erfahrung mit hast. Erfahrung ist fast schon zu viel gesagt. Alles was ich gebastelt habe ist eine Uhr mit DCF77 Vielen Dank schonmal für die vielen Vorschläge. Jetzt fehlt mir nur das nötige Wissen, um zu entscheiden, welche MCU hier die "beste" Wahl wäre.
M.A. S. schrieb: > ob es irgend ein > TI-Bauteil gibt, das momentan erhältlich ist. > Wir haben damit gerade so unsere Probleme... Echt? Ich verarbeite, ...na ja Gefühlt.. Tonnenweise MSP430 und habe keine Probleme mit Nachschub.... Aber ich würde für dieses Projekt, eigentlich auch ein MSP430FR oder MSP430G in Erwägung ziehen. Wenn du nur 1~3 Stück brauchst, kannst du sogar ein Kostenloses Sample bei TI Bestellen. Im Gegensatz zu STM die doch das Porto für Samples einfordern ist bei TI sogar das umsonst ;-)
ATTiny 24/44/84 hat schon fast zu viele Pins. Da meist I²C und SPI auf den gleichen Pins liegen bei den kleinen Dingern, solltest du für eines der beiden Interfaces Bitbanging vorsehen oder eine Library verwenden, die beliebige Pinbelegungen ermöglicht. Sleep Modes können so gut wie alle AVR, am wichtigsten dabei ist der Strom über I/O Pins, die alle auf minimalen Strom gesetzt werden sollten. LoRa kann man entweder direkt aus einem Port speisen (das mache ich mit HopeRF Modulen) oder zumindest über einen Port schalten, wenn das Modul selber keinen anständigen PowerDown Mode hat.
Matthias S. schrieb: > LoRa kann man entweder direkt aus einem Port speisen Das war auch mein Plan bis jetzt, mein Modul zieht im Sleep 10mA, das ist mir für low Power etwas zu viel Vor Bitbanging wollte ich mich eigentlich drücken...
Fuer richtig bodenstaendige Projekte braucht es bodenstaendige Controller. Von Philips z.B. den XA-G4 oder einen eCOGx1. Zur Not kann man auch Intels 251er benutzen. Alles ungefaehr die gleiche Leistungsklasse. Das Gute an diesen Controllern ist, das koennen die Chinesen nicht einfach nachbauen. So sicherst du aktiv deine Innovation.
Praktisch alle Hersteller von Mikrocontrollern haben auf ihren Internetseiten tabellarische Listen (üblicherweise Excel), die die Eigenschaften ihrer Bauteile auflisten. Da kannst Du ganz bequem auswählen, was das Zeug hält.
Sebastian S. schrieb: > Praktisch alle Hersteller von Mikrocontrollern haben auf ihren > Internetseiten tabellarische Listen (üblicherweise Excel), die die > Eigenschaften ihrer Bauteile auflisten. > Da kannst Du ganz bequem auswählen, was das Zeug hält. Ist doch immer der gleiche Quatsch mit Anfängern. Da blinkt noch nicht mal ne LED ohne Arduino-Framework und dann kommt die Frage nach einer Empfehlung. Als ob solche Leute mal schnell mit irgendeinem Controller arbeiten könnten. Das ist doch utopisch.
Cyblord -. schrieb: > Da blinkt noch nicht > mal ne LED ohne Arduino-Framework und dann kommt die Frage nach einer > Empfehlung. Ganz so schlimm ist es um meine Kenntnisse dann doch nicht bestellt. Ich beherrsche zumindest teilweise C und mit Arduino und dem Raspberry Pi Pico habe ich schon ein bisschen was gemacht
Cyblord -. schrieb: > Als ob solche Leute mal schnell mit irgendeinem Controller arbeiten > könnten. Das ist doch utopisch. Nö. Aber bei so einem Projekt kann man viel lernen und den "Absprung" von vorgefertigten Libraries und Frameworks wagen. Das Projekt klingt jetzt nicht zuuu schwierig und für viele genannte Controller gibt es Communities, die unterstützen. STM32 mit HAL finde ich etwas komplizierter als den MSP430 bare-metal, liegt aber einfach daran, dass ich jahrelang auf dem AVR entwickelt habe und der MSP430 gar nicht sooo verschieden ist. Anstatt "Quatsch" und "utopisch" zu rufen, fände ich es besser, Unterstützung und realistische Einschätzungen abzugeben. Einen neuen Controller kennenzulernen, gerade wenn man vom Arduino-Framework etwas verwöhnt ist, ist eine Herausforderung, aber es ist ein wichtiger Schritt, den man gut gehen kann, wenn man uC-Programmierung ein bisschen verstanden hat. Die ganzen Register, timed sequences,... muss man sich dann halt mit Datenblättern und Beispielcode drauf schaffen. Das braucht Zeit, ist aber machbar. (Und notfalls gibt's für STM32 und MSP430 auch das Arduino-Framework (STM32Duino und TIs eigenes Energia) - aber pssssst)
David P. schrieb: > Vor Bitbanging wollte ich mich eigentlich drücken... Dann nimm doch eine fertige Library. Für I2C auf AVR nutze ich die von P. Fleury und das klappt bestens.
Auf Deine Anforderungen passen relativ viele uCs. Mal so als Beispiel: https://www.digikey.de/de/products/detail/microchip-technology/PIC16F18345-I-P/5323640 https://www.microchip.com/en-us/product/PIC16F18345 - ist tatsächlich kaufbar - hat XLP, die Microchip-Variante von Low-Power-Modi, geht im Sleep-Mode unter den 100nA-Bereich - hat zwei MSSP-Ports (umschaltbar zwischen SPI und I2C) - hinreichend IOs - gibts in DIL - läuft von 2.3V bis 5.5V, je niedriger die Betriebsspannung, desto kleiner der Stromverbrauch - läuft ab 2.5V mit seinen vollen 32MHz (im Gegensatz zu den klassischen AVRs, die nur im 5V-Betrieb mit ihrer vollen Taktrate arbeiten) - recht einfache und übersichtliche Architektur - Codegenerator im MPLABX - Einfache Beschaltung: 100nF zwischen VDD und VCC, 10k zwischen VCC und MCLR, MCLR und ICSPCLK und ICSPDAT ans PICKIT3, und dann läuft das Teil. Du wirst feststellen, dass hier viele Leute Microchip und PIC aus verschiedenen Gründen nicht mögen. Manche finden die Architektur doof, andere stören sich daran, dass Microchip seine Tools und Bibliotheken nicht GPL-lizensiert rausgibt, manche mögen das MPLABX nicht. Vieles ist dabei subjektiv, und ein wirklich relevantes Hindernis für Dich ist nichts davon. MPLABX und XC8 sind für Dich kostenlos benutzbar und einen PICKIT3-Clone zum Programmieren bekommst Du für 20€. fchk
Krass was an low Power Chips so möglich ist, ich dachte wenn man weit unter ein mA braucht, kommt man an sleep modes nicht vorbei, aber das stimmt ja scheinbar so gar nicht.
Frank K. schrieb: > https://www.digikey.de/de/products/detail/microchip-technology/PIC16F18345-I-P/5323640 > https://www.microchip.com/en-us/product/PIC16F18345 Der Datenblatt ließt sich richtig gut, allerdings habe ich auch mal ein wenig gegoogled und es hieß, der ließe sich nicht gut in C programmieren, da es kaum vernünftige Compiler gäbe. Auf Assembler Level wollte ich eigentlihc nicht gehen, da fehlt mir tatsächlich komplett die Erfahrung
David P. schrieb: > Der Datenblatt ließt sich richtig gut, allerdings habe ich auch mal ein > wenig gegoogled und es hieß, der ließe sich nicht gut in C > programmieren, da es kaum vernünftige Compiler gäbe. Das sich die kleinen PICs nicht gut für C eignen, mag sicher für den 16F84 oder so von vor 20 Jahren zutreffen. Bei den aktuellen 16er PICs sollte es da keine größeren Probleme geben. Zumal du ja dem Compiler C-Code vor die Füße wirfst und er kümmert sich darum, was im PIC passiert. Ok, ein paar Spezialitäten wie die Interrupts hat man trotzdem noch, das ist aber kein Hexenwerk. Ansonsten nimmst du halt einen PIC18, die sind "etwas besser" für C optimiert. Als IDE steht MPLAB X zusammen mit dem XC8 kostenlos zur Verfügung. Die Einarbeitung ist etwas gewöhnungsbedürftig, was aber auf jede neue Plattform zutrifft. Ganz wichtige Frage ist auch noch, ob dein ausgesuchter µC lieferbar ist. Viel Erfolg.
David P. schrieb: > Frank K. schrieb: >> > https://www.digikey.de/de/products/detail/microchip-technology/PIC16F18345-I-P/5323640 >> https://www.microchip.com/en-us/product/PIC16F18345 > > Der Datenblatt ließt sich richtig gut, allerdings habe ich auch mal ein > wenig gegoogled und es hieß, der ließe sich nicht gut in C > programmieren, da es kaum vernünftige Compiler gäbe. Auf Assembler Level > wollte ich eigentlihc nicht gehen, da fehlt mir tatsächlich komplett die > Erfahrung Das war mal. Zum Einen haben moderne PIC16 viele Erweiterungen vom PIC18 geerbt, was es für Compiler einfacher macht. Zum Anderen ist der XC8 inzwischen soweit ganz brauchbar. MPLABX hat Netbeans als Grundlage, so wie andere auf Eclipse aufsetzen. Du verlierst zwei Pins für den Debugger (ISPCLK und ISPDAT). Im Gegensatz zu den klassischen AVRs kannst Du Dich nicht aussperren - Programmieren geht immer. Und Du kannst debuggen (Speicher, Register und Variablen anschauen, Einzelschritt, ...). Das nächstgrößere wäre z.B. der PIC24F32KA301: https://www.digikey.de/de/products/detail/microchip-technology/PIC24F32KA301-I-P/2651306 https://ww1.microchip.com/downloads/en/DeviceDoc/30009995e.pdf Das ist ein 16 Bit Prozessor, dessen Kern für C gebaut worden ist. Der Prozessorkern ist also ein völlig anderer (und das wissen viele Leute nicht - die verbinden mit PIC nur die 8-Bit Architekturen), die Peripherie hingegen ist ziemlich ähnlich - kennst Du einen, kennst Du sie im Prinzip alle. IDE und Debugger bleiben gleich, nur der Compiler ist ein anderer (XC16). Das ist ja das schöne: Du kannst mit der gleichen Umgebung von kleinen 6-Pinner (PIC10F200, Äquivalent zum Attiny 10) bis hin zu 300 MIPS 32 Bit Prozessoren alles bedienen. fchk
Frank K. schrieb: > Äquivalent zum Attiny 10) bis hin zu 300 > MIPS 32 Bit Prozessoren alles bedienen. Hast somit eine riesen Auswahl..... ;-) Nun wenn du wert auf möglichst wenig Saftverbrauch legst, also Batteriebetrieb, dan würde ich mir doch nochmals die MSP430 Familie anschauen, da gibt es welche die selbst bei 8 MHz noch im 2 stelligen µA bereich laufen. und im LPM5 Mode weit unter 1 µA Liegen. Auch gibt es MSP430 die bemerkenswerte Peripherie wie Analog OpAmp AD, DA USI bis zu 10 Stück! (I²C SPI UART) usw. Onboard haben. Auch die verschiedenen Launchpad's können dir viel Zeit ersparen, weil du die ohne Lötarbeit gradenwegs verwenden kannst. Auch die verschiedenen Oberflächen(IDE) die es gibt sind sehr hilfreich und alle Kickstarter kostenlos.(Inkl "C" Compiler). Gruß und viel Erfolg....
:
Bearbeitet durch User
David P. schrieb: > Krass was an low Power Chips so möglich ist, ich dachte wenn man weit > unter ein mA braucht, kommt man an sleep modes nicht vorbei, aber das > stimmt ja scheinbar so gar nicht. Das können heutzutage alle MC-Familien. Die MCs sind CMOS, d.h. die Stromaufnahme hängt linear von der Frequenz und von der VCC ab. Schau z.B. mal ins Datenblatt des ATtiny24, bei 128kHz/1,8V zieht er ~30µA (8µA in Idle): Figure 21-5. Active Supply Current vs. VCC (Internal RC Oscillator, 128 kHz)
:
Bearbeitet durch User
Matthias S. schrieb: > ATTiny 24/44/84 hat schon fast zu viele Pins. Davon würde ich die neueren Typen empfehlen, die ein richtiges TWI haben. Ein günstiges Entwicklungsboard: https://www.mouser.de/ProductDetail/Microchip-Technology/ATTINY416-XNANO?qs=1mbolxNpo8fQGr9Vr3B9Wg%3D%3D und jede Menge auf Lager: https://www.mouser.de/ProductDetail/Microchip-Technology/ATTINY416-SF?qs=3HJ2avRr9PKRKlrtbpdofw%3D%3D
Patrick L. schrieb: > M.A. S. schrieb: >> ob es irgend ein >> TI-Bauteil gibt, das momentan erhältlich ist. >> Wir haben damit gerade so unsere Probleme... > > Echt? > > Ich verarbeite, ...na ja Gefühlt.. Tonnenweise MSP430 und habe keine > Probleme mit Nachschub.... Ich schrieb ja, dass ich mit MSP430 nichts zu tun habe, bei mir geht es also um andere TI-Bauteile. Wie das bei dieser Controller-Familie ist, weiß ich nicht, aufgrund meiner jüngsten Erfahrungen meide ich TI halt. Aber bei anderen Herstellern ist es gerade ähnlich schlimm...
:
Bearbeitet durch User
> Das können heutzutage alle MC-Familien. Die MCs sind CMOS, d.h. die > Stromaufnahme hängt linear von der Frequenz und von der VCC ab. Das stimmt so einfach nicht oder nicht mehr. Vor 10-15Jahren war stromsparen was besonderes. Damals war das ein Alleinstellungsmerkmal der MSP430. Alle anderen waren deutlich schlechter. Dann haben die nachgezogen und sind jetzt genauso gut oder sogar besser. Da tauchten dann (Gecko/Silabs) mit Automatismen auf wo der Mikrocontroller im Sleepmode bleiben konnte, aber trotzdem irgendwas machen konnte. (z.B ein serielles Paket empfangen) Mittlerweile findet aber gerade wieder ein Wechsel statt weil man mehr Taktfrequenz haben moechte und dann Sleepmode nicht mehr so einfach ist. (Leckstroeme steigen) Schlimmste Beispiel das ich da gesehen habe ist der RP2040 wo die mit Sleepmode 1mA meinen. (da liegt man vor lachen auf dem Tisch) Renesas hat da derzeit eine Spezialloesung um gleichzeitig schnell und trotzdem stromsparend sein zu koennen. Wenn man aber wirklich in den bereich von wenigen uA runter will dann kommt es sehr darauf an das der Mikrocontroller gut zum Projekt passt. Aber fuer die Androidbastelfraktion die sowieso keine Ahnung hat und sich Source anderer Leute zusammenklaut ist dass irgendwann egal weil die eh immer eine Groessenordung schlechter sind als es sein muesste. Olaf
Olaf schrieb: > Vor 10-15Jahren war > stromsparen was besonderes. Damals war das ein Alleinstellungsmerkmal > der MSP430. Alle anderen waren deutlich schlechter. Ja das ist so, die ersten µC die damals im µA bereich waren, waren die EM-Marin 4Bit µC (wurden in den Swatch verbaut). dann kam TI, und schob das ganze an mit direkt von 4Bit auf 16Bit. Jahre später zogen dann immer mehr Hersteller nach, selbst TI baute 8051er Core in der CC430 Familie in LowEnergy . Heute hat TI zwar wieder einen Vorsprung in LowEnergy , dank den FRAM, die sind einiges besser als jeder Flash µC, was LowEnergy betrifft. Auch die Möglichkeit den FRAM als VRAM Speicher zu nutzen, gibt ihnen ein klaren Vorteil. Was viele nicht wissen: Wenn es auf LowEnergy ankommt, sollte bei FLASH µC, die Running Software im RAM liegen, den bei FLASH-Access verbrauchen sie deutlich mehr Strom als bei abarbeiten im SRAM. Das macht dann die Software Gestaltung etwas komplexer. Da haben die FRAM basierenden µC wieder ihr Vorteil, den FRAM braucht bei gleicher Geschwindigkeit deutlich weniger Strom als bei Abarbeiten aus dem FLASH. Auch die Peripherie in den MSP's ist in vieler Hinsicht heute noch besser für LowEnergy ausgelegt, so lassen sich einzelne "Peripherie Blöcke" gezielt ein und aus-schalten, oder werden je nach LPM Mode direkt Verwaltet. Und eben das Nutzen eines Teils des FRAM als NVRAM macht da auch noch etwas aus, vor allem eben im Lowenergy bereich, man braucht keine Energye um das SRAM zu "halten" wenn man die Parameter ins FRAM legt. dan kann der µC in Tiefschlaf gehen und nur noch nA nutzen. Allerdings muss man da extrem auf Layout, PCB Material und Schutzlack achten, damit die Kriechströme auf dem PCB nicht in zig µA gehen, sonnst nützt das ganze LowEnergy nix ;-)
:
Bearbeitet durch User
Angehängte Dateien:
-
AT89C2051_active.png
13 KB
Olaf schrieb: > Vor 10-15Jahren war > stromsparen was besonderes. Das stimmt so nicht. Z.B. der AT89C2051 kam 1993 raus und konnte ständig an 2 AA-Batterien hängen (20µA Powerdown, 1mA Idle). Ich hab damit nen Würfel aufgebaut, mit dem Taster wachte er auf, mit dem Timer ging er schlafen. Ist schon 29 Jahre her. Es reicht völlig, wenn man soviel Strom spart, daß es für den geplanten Einsatzzweck reicht. Ob da jemand noch einige µA besser ist, spielt keine Rolle.
:
Bearbeitet durch User
Wenn es um Ultra LowEnergy geht hier ein guter Bericht dazu, auf was man so achten sollte. https://www.all-electronics.de/elektronik-entwicklung/ultra-low-power-benchmarks-fuer-mikrocontroller.html
Patrick L. schrieb: > Wenn es um Ultra LowEnergy geht Wie gesagt, darum geht es nie. Ein professioneller Entwickler rechnet aus, welchen Strom die gesamte Schaltung maximal verbrauchen darf und richtet sich danach. Oftmals ist nämlich der MC nicht der Hauptverbraucher. Man muß also mit ausrechnen was die anderen Lasten benötigen, wenn der MC aktiv ist. Immer nur so gut sein, wie nötig.
:
Bearbeitet durch User
> Es reicht völlig, wenn man soviel Strom spart, daß es für den geplanten > Einsatzzweck reicht. Ob da jemand noch einige µA besser ist, spielt > keine Rolle. Da sind meine Erfahrungen 100% anders. Je sparsamer man es bekommt umso mehr Funktionen kann man wiederum einbauen welche die Konkurenz dann nicht hat und mit 1mA betreibt man heute drei Microcontroller, ein LCD und ein analoges Frontend. Jedes uA zaehlt! Olaf
Da ich eben in einem anderen Post erfahren habe, dass mein Atmega1284p (zumindest teilweise) defekt ist, muss ich mich definitiv nach was neuem umsehen. Schade, dass sowas defekt vom Hersteller kommt, aber dann hätte ich ihn wohl direkt nach Kauf ganz testen sollen
David P. schrieb: > Da ich eben in einem anderen Post erfahren habe, dass mein Atmega1284p > (zumindest teilweise) defekt ist, muss ich mich definitiv nach was neuem > umsehen. Schade, dass sowas defekt vom Hersteller kommt, aber dann hätte > ich ihn wohl direkt nach Kauf ganz testen sollen Auch nach der Lektüre dieses besagten Threads, glaube ich keine Sekunde an einen defekten Controller. Jeder zweite Anfänger der nicht Programmieren und nicht Messen kann, stellt nach 10 Minuten fest: "Controller defekt. Blöder Lieferant. Zum Glück lag es nicht an mir". Und kauf dir das nächste mal vielleicht mehr als einen einzigen Controller. Wer macht denn sowas?
David P. schrieb: > dass mein Atmega1284p > (zumindest teilweise) defekt ist Sehr unwahrscheinlich. Liegt eher am Steckbrett, der Verdrahtung oder dem Uhrenquarz.
Peter D. schrieb: > Es reicht völlig, wenn man soviel Strom spart, daß es für den geplanten > Einsatzzweck reicht. Ob da jemand noch einige µA besser ist, spielt > keine Rolle. Dem stimme ich voll und ganz zu. Ich denke, das LORA-Modul wird einige Zehnerpotenzen mehr Energie benötigen als der Prozessor. Ja Patrick, Du hast mit Deinen Ausführungen von der Sache her völlig Recht. Aber der Fragesteller ist Anfänger, und er braucht eine Plattform, mit der er möglichst viele verschiedene Probleme erledigen kann, von klein bis groß, und mit einer großen Auswahl an Peripherie. Beispielsweise CAN oder Ethernet. OpAmps, Komparatoren, ADCs und DACs gibts bei PICs auch, und auch so nette Sachen wie CLC (programmierbare Logikhardware). Auch wenn er irgendwann mal mehr Rechenleistung haben will, würde er bei MSP430 an eine harte Grenze stoßen. Es gibt mittlerweise auch Dual Core PICs. Ich habe ihm daher extra Vorschläge gemacht, die für ihn vom Leistungsverbrauch her gut genug sind, die ihm aber eine Perspektive für mehr bieten. fchk
Cyblord -. schrieb: > Und kauf dir das nächste mal vielleicht mehr als einen einzigen > Controller. Wer macht denn sowas? Ich hatte besagten Controller übrig, da ich mehr als einen bestellt hatte. Und zur Diagnose "defekt" kam ich durch die erste Antwort in dem Thread....
David P. schrieb: > Und zur Diagnose "defekt" kam ich durch die erste Antwort in dem > Thread.... Typische Fehldiagnose würde ich sagen. Deshalb lässt man den Oberarzt die Diagnosen stellen und nicht die Putzfrau.
:
Bearbeitet durch User
Peter D. schrieb: > Wie gesagt, darum geht es nie. Ist so nicht Richtig. Wir haben Projekte, wo es um Implantate geht und wir haben Aktuell Projekte für "Aerospace & Defense" wo jedes nA Zählt da sind wir mit einem MSP430Lxx im pW/h bereich, was ich mit keinem anderen µC hinkriege. Für den TO wohl völlig Uninteressant, da man da auch mit "C" massiv den Kopf anschlägt. Da ist Assembler wohl noch fast die Einzige Möglichkeit die Letzten pA rauszukitzeln. (und jetzt bitte keine Assembler vs "C" Diskusion starten, DANKE ) Deshalb: Frank K. schrieb: > Ich habe ihm daher extra Vorschläge gemacht, die für ihn vom > Leistungsverbrauch her gut genug sind, die ihm aber eine Perspektive für > mehr bieten. Muss ich dir absolut Zustimmen, auch wenn ich selber lieber die MSP430 er einsetze, dann aber doch aus der Erfahrung seit es die gibt Somit ist: Patrick L. schrieb: > Frank K. schrieb: >> Äquivalent zum Attiny 10) bis hin zu 300 >> MIPS 32 Bit Prozessoren alles bedienen. > > Hast somit eine riesen Auswahl..... ;-) Die erste Wahl für den TO 73 55
:
Bearbeitet durch User
David P. schrieb: > gut benutzbare Sleep Modes Was auch immer das bedeuten mag. Sleep Modi hat praktisch jeder Mikrocontroller. Was soll er denn im Sleep können? Da unterscheiden sie sich. > Es geht darum, Daten zu sammeln Wie viele ist egal? Mein "heiß geliebter" ATtiny13A hat 64 Bytes RAM.
Patrick L. schrieb: > da man da auch mit "C" massiv den > Kopf anschlägt. Da ist Assembler wohl noch fast die Einzige Möglichkeit > die Letzten pA rauszukitzeln. Dann muß der MSP Compiler aber wirklich grottenschlecht sein, um einen meßbaren Unterschied zu erkennen. Heutige Compiler nehmen sich kaum was mit Assembler. Im Gegenteil, C-Code wird oft besser optimiert, als ein mittelmäßiger Assemblerprogrammierer es je könnte. Es sei denn, man legt dem Compiler absichtlich Steine in den Weg, z.B. nimmt für sämtliche Variablen 80 Bit long double. Als ich beim 8051 von Assembler auf C umgestiegen bin, war ich völlig ernüchtert. Der Compilercode lief doppelt so schnell und das Binary war nur halb so groß. Meine ganzen mühsam erstellten Assembler Libs habe ich nach dev/null verschoben. An einem Compiler bauen viele Experten herum, die Assembler besser als jeder von uns beherrschen. Da stecken also Mannjahrhunderte an Wissen und Erfahrung drin.
Stefan ⛄ F. schrieb: > Was auch immer das bedeuten mag. Sleep Modi hat praktisch jeder > Mikrocontroller. Was soll er denn im Sleep können? Da unterscheiden sie > sich. Naja ich kenne es vom RP2040, dass die Sleep Modes ein wenig aufwand bedeuten. Bei AVR sind es 2 Befehle und wenn er wieder aufwacht kann man weiter machen, als wäre nichts gewesen. Wenn man den RP2040 in sleep schickt und wieder aufweckt muss man alle möglichen Takte wieder manuell setzen, sonst macht der gar nichts Stefan ⛄ F. schrieb: > Wie viele ist egal? Mein "heiß geliebter" ATtiny13A hat 64 Bytes RAM. Ich gehe von Datenpaketen von 6 Byte aus. Aber 64 Byte Ram werden schon vom programmieren glaube ich etwas schwierig.
David P. schrieb: > Wenn man den RP2040 in sleep schickt und wieder aufweckt muss man alle > möglichen Takte wieder manuell setzen, sonst macht der gar nichts Das ist wohl eine Frage der verfügbaren Bibliotheken. Dem RP2040 fehlen 10 oder 20 Jahre, die andere Mikrocontroller schon gereift sind. Will sagen: Schau dich lieber nach Modellen/Serien um, die wesentlich älter sind.
Stefan ⛄ F. schrieb: > Will sagen: Schau dich lieber nach Modellen/Serien um, die wesentlich > älter sind. Ich habe jetzt einfach mit dem atmega1284p angefangen, wie es auch jemand vorgeschlagen hat. Wenn ich abschätzen kann, wie viel Ram/Rom ich brauche, kann ich ja was passendes, kleineres suchen.
David P. schrieb: > Naja ich kenne es vom RP2040, dass die Sleep Modes ein wenig aufwand > bedeuten. Bei AVR sind es 2 Befehle und wenn er wieder aufwacht kann man > weiter machen, als wäre nichts gewesen. Nunja, ein wenig mehr ist es auch beim AVR8 u.U. schon, aber wirklich noch einfach zu beherrschen. > Wenn man den RP2040 in sleep > schickt und wieder aufweckt muss man alle möglichen Takte wieder manuell > setzen, sonst macht der gar nichts Natürlich. "In sleep schicken" bedeutet ja im Kern hauptsächlich, die meisten oder gar alle Takte abzuschalten. Das ist aber im Prinzip beim AVR8 ganz genauso. Der Unterschied besteht schlicht darin, dass das Taktsystem des RP2040 ganz erheblich komplexer ist und, dass es anders als beim AVR8, es auch keine "automatische Taktanforderung" gibt. Die ist dort nur deshalb möglich, weil es eine rein binäre Entscheidung ist: ich brauche diesen und jenen Takt oder ich brauche ihn nicht. Beim RP2040 hingegen kann man einen bestimmten Takt gewöhnlich auf 'zig verschiedene Arten bereitstellen. Aber: ich sehe da eigentlich kein großes Problem. Jede Anwendung muss ja sowieso beim initialen Startup ihr Taktsystem aufbauen. Dieselbe Routine ruft man einfach nach dem Aufwachen erneut auf und gut isses. Wobei natürlich das oft nicht der energetisch günstigste Weg ist, sondern auch bloß Schema F. Es kann nämlich gut sein, dass beim Aufwachen garnicht das ganze voll ausgerüstete Schlachtschiff nötig ist, sondern nur minimale Teile davon. Hängt i.d.R. vom Grund des Aufwachens ab... Oder anders ausgedrückt: Man muss da einfach viel mehr drüber Nachdenken, als bei simplen AVR8 (wobei sich das auch bei denen schon durchaus lohnen kann).
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.