Forum: Mikrocontroller und Digitale Elektronik Mikrocontroller Empfehlung gesucht


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von David P. (devryd)


Lesenswert?

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

von Sebastian R. (sebastian_r569)


Lesenswert?

Für Low-Power geht z.B. die MSP430-Serie von TI ganz gut. Ansonsten 
STM32L0, die dürften aber schwerer zu bekommen sein.

von Εrnst B. (ernst)


Lesenswert?

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)...

von M.A. S. (mse2)


Lesenswert?

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...

von Boris (Gast)


Lesenswert?

Oder die EFM32 von Silabs

von David P. (devryd)


Lesenswert?

Ε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.

von Patrick L. (Firma: S-C-I DATA GbR) (pali64)


Lesenswert?

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 ;-)

von Matthias S. (Firma: matzetronics) (mschoeldgen)


Lesenswert?

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.

von David P. (devryd)


Lesenswert?

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...

von oernithologe (Gast)


Lesenswert?

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.

von Sebastian S. (amateur)


Lesenswert?

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.

von Cyblord -. (cyblord)


Lesenswert?

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.

von David P. (devryd)


Lesenswert?

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

von Sebastian R. (sebastian_r569)


Lesenswert?

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)

von Matthias S. (Firma: matzetronics) (mschoeldgen)


Lesenswert?

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.

von Frank K. (fchk)


Lesenswert?

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

von David P. (devryd)


Lesenswert?

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.

von David P. (devryd)


Lesenswert?

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

von Jens P. (picler)


Lesenswert?

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.

von Frank K. (fchk)


Lesenswert?

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

von Patrick L. (Firma: S-C-I DATA GbR) (pali64)


Lesenswert?

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
von Peter D. (peda)


Lesenswert?

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
von Andreas (Gast)


Lesenswert?

Suche mal nach "Lilygo LoRa"

von m.n. (Gast)


Lesenswert?

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

von M.A. S. (mse2)


Lesenswert?

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
von Olaf (Gast)


Lesenswert?

> 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

von Patrick L. (Firma: S-C-I DATA GbR) (pali64)


Lesenswert?

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
von Peter D. (peda)


Angehängte Dateien:

Lesenswert?

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
von Patrick L. (Firma: S-C-I DATA GbR) (pali64)


Lesenswert?

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

von Peter D. (peda)


Lesenswert?

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
von Olaf (Gast)


Lesenswert?

> 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

von David P. (devryd)


Lesenswert?

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

von Cyblord -. (cyblord)


Lesenswert?

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?

von Peter D. (peda)


Lesenswert?

David P. schrieb:
> dass mein Atmega1284p
> (zumindest teilweise) defekt ist

Sehr unwahrscheinlich.
Liegt eher am Steckbrett, der Verdrahtung oder dem Uhrenquarz.

von Frank K. (fchk)


Lesenswert?

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

von David P. (devryd)


Lesenswert?

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....

von Cyblord -. (cyblord)


Lesenswert?

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
von Patrick L. (Firma: S-C-I DATA GbR) (pali64)


Lesenswert?

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
von Stefan F. (stefanus)


Lesenswert?

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.

von Peter D. (peda)


Lesenswert?

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.

von David P. (devryd)


Lesenswert?

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.

von Stefan F. (stefanus)


Lesenswert?

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.

von David P. (devryd)


Lesenswert?

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.

von c-hater (Gast)


Lesenswert?

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).

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.