Forum: Mikrocontroller und Digitale Elektronik Auf der Suche nach einem ultra low power Mikrocontroller (mit BLE)


von Jonas B. (holocron)


Lesenswert?

Hallo,

ich bin für ein Uni-Projekt auf der Suche nach einem ultra low power 
Mikrocontroller. Für die Geschwindigkeit sind die Anforderungen sehr 
gering. Er generiert mit einem 1 Hz Rechtecksignale (5 V Amplitude) um 
aus einer Impulsantwort eine Kapazität zu bestimmen und die Messung zu 
speichern (genauer die Zeitkonstante).
Optional sollte er über BLE verfügen (um die Daten auf einen PC 
übertragen zu können), aber notfalls kann ich darauf verzichten und ein 
Busprotokoll mit Kablen verwenden (also an den PC anschließen). Ich 
versuche nur darum einen Bogen zu machen, weil das Gehäuse, in welches 
er verbaut wird, nass werden können muss und ich es kalbellos handlicher 
fände.

Ich hab gesehen, das es bereits Beiträge in diese Richtung gibt, 
allerdings ist das ja wiederum auf jede Anwendung zugeschnitten. Im 
Internet hab ich hierzu ein breites Spektrum gefunden, allerdings weiß 
ich nicht welche für diese Anwendung geeignet wäre. Vor allem für welche 
mit BTE konnte ich um ultra low power Bereich (fast) nichts finden.

Danke und Grüße

: Bearbeitet durch User
von micha (Gast)


Lesenswert?

Sollen die Daten kontinuierlich oder nur auf Anforderung übertragen 
werden? Im letzteren Fall geht jeder mc und ein Bluetooth Modul das nur 
bei Bedarf angestellt wird (zB über Magnetschalter getriggert). 
Ansonsten schwierig, für Bastler wahrscheinlich am einfachsten mit einem 
esp32

von Chris K. (Gast)


Lesenswert?

BLE ist dafür gemacht mit ner Knopfzelle zu laufen. Fast jeder BLE Chip 
hat einen ARM mit drin und die können ULP. Sind dann allerdings nur 3V3.

Siehe
CC26xx von TI
RSL1x von OnSemi
KWxx von NXP
CSR, Dialog Semi, Nordic, ST, Toshiba, Telink etc.

von Olaf (Gast)


Lesenswert?

> ultra low power Mikrocontroller.

Noch feucht hinter den Ohren, aber schon Bullshitwoerter? :-)

> nass werden können muss und ich es kalbellos handlicher
> fände.

Solltest du mit "nass" mehr als ein paar Regentropfen meinen, Wasser ist 
eine gute Abschirmung fuer HF.

Es gibt bergeweise BLE Controller. Einer der ersten und verbreitesten 
duerfte der Nordic nrf51822 sein.

https://www.seeedstudio.com/blog/2019/11/22/nrf51822-ble-module-getting-started-and-arduino-compatability/

Die Toolchain von Nordic erinnert aber immer an Seufzerbruecke in 
Thermomix. :-)

Olaf

von Schorschi (Gast)


Lesenswert?

State of the art sind im Moment die nRF52 microcontroller von Nordic 
sowie der Ambiq Apollo 3 (4) von Ambiq Micro.

von Schorschi (Gast)


Lesenswert?

Olaf schrieb:
> Einer der ersten und verbreitesten
> duerfte der Nordic nrf51822 sein.

Ja, war mal verbreitet. Mittlerweile ist er aber schon seit einigen 
Jahren vom nRF52832 und nRF52840 abgelöst. Es gibt nun abgesehen von 
diesen 2 etwa 5 weitere MCU in der gleichen Familie mit leicht anderen 
Peripherals.

von Olaf (Gast)


Lesenswert?

> Ja, war mal verbreitet.

Klar, mittlerweile baut ja jeder was mit BLE was nicht bei drei auf den 
Baeumen ist.

Ein Tip an die Anfaenger: Schaut euch erst mal die Qualitaet der 
Entwicklungsumgebung an  bevor ihr eine Entscheidung trefft. Ich hab 
letztens etwas aktuelles von Nordic rausgeworfen weil das einfach nicht 
zu ertragen war.

Olaf

von MaWin (Gast)


Lesenswert?

Jonas B. schrieb:
> kalbellos handlicher fände.

Was ist an einer Batterie, die ständig leer ist, und an einem Gerat das 
ständig das pairing verliert, und einer Antenne handlich ?

Jonas B. schrieb:
> Busprotokoll mit Kablen

Eindeutig vorzuziehen.
Erstens interessiert dich dann die Leistungsaufnahme nicht, weil das 
Ding über das Schnittstellenkabel versorgt werden kann (parasitic 
power), dazu braucht man nichtmal eine extra Leitung, siehe DS1820 
OneWire Schnittstelle.

Zweitens lassen sich Schaltungen ERHEBLICH kleiner bauen, wenn nicht 
Batterie und Antenne untergebracht werden müssen und man zudem 
verhindern muss dass die Antennenabstrahlung dir in die Leitungen zum 
Messen reinfunkt und damit die Messwerte zerstört.

Zudem lassen sich Schaltungen an Kabeln erheblich einfacher in einem 
Gehäuse wasserdicht verbauen, wenn nicht eine benutzerzugängliche 
Batterie drin sein muss. Und viertens ist bei Messtechnik ein Störungen 
abschirmendes Metallgehäuse möglich  wenn die Schaltung nicht rausfunken 
können muss.

Also: wer Funk kennt, nimmt Kabel.

von H. B. (Gast)


Angehängte Dateien:

Lesenswert?

Wir verwenden den DA14682 von Dialog Semi.
Ein toller Baustein.
Extrem klein, ARM intern, DC/DC-Wandler intern, LDO´s intern, BTLE5.0 
intern, Li ion Charger mit Powerpath intern, ultrageringer 
Stromverbrauch, kann auch mit einer 3V Knopfzelle betrieben werden.

von Olaf (Gast)


Lesenswert?

> Was ist an einer Batterie, die ständig leer ist, und an einem Gerat das
> ständig das pairing verliert, und einer Antenne handlich ?

Du hast bei BLE kein Pairing. Du koenntest vermutlich sogar im 
Advertisingmode einmal pro Sekunde 2-3x 16Bit Werte an jedem verschicken 
und das aus einer 2032 ein Jahr lang und als Antenne tut es ein 18x24 
Dingen auf der Platine das wie ein Widerstand aussieht. Das ist schon 
ziemlich cool. Und als Empfaenger geht jedes Handy.

> Also: wer Funk kennt, nimmt Kabel.

Das stimmt auch, aber vor allem wegen der Softwareentwicklung. Ich 
vermute das kann einen Anfaenger schnell ueberfordern.

Olaf

von Jonas B. (holocron)


Lesenswert?

Hallo,
danke für die vielen Rückmeldungen und Empfehlungen. Das Signal über BLE 
sollte nur auf Befehl übertragen werden, aber angesichts der 
aufgeführten Tatsachen, scheint es mir auch am besten die Kabel zu 
verwenden. Eine auswechselbare Batterie (Knopfzelle) wird allerdings auf 
jeden Fall benötigt werden.

Was wäre denn (mit der angeforderten, keinen BLE zu verwenden) ein 
geeigneter µC? Ich hab im Internet hierzu zahllose ultra low power µC 
gefunden, allerdings ist das schwer zu beurteilen (wo die Vor- und 
Nachteile liegen etc.).

Danke und Grüße

von Ben S. (bensch123)


Lesenswert?

Jonas B. schrieb:
> Ich hab im Internet hierzu zahllose ultra low power µC
> gefunden, allerdings ist das schwer zu beurteilen (wo die Vor- und
> Nachteile liegen etc.).

Dein Problem ist asbach. Nimm irgendeinen kleinen 8bit und versetz den 
regelmäßig in Sleep Mode. Oder so ...

von Hermann Kokoschka (Gast)


Lesenswert?

Jonas B. schrieb:
> Eine auswechselbare Batterie (Knopfzelle) wird allerdings auf
> jeden Fall benötigt werden.

Erkläre bitte mal warum.
Wenn Du eh schon kabelgebunden arbeitest...

von Uwe (Gast)


Lesenswert?

Danke, kannte ich noch nicht... Die machen ja mal ein paar ausgefallene 
Dinger...

von Jonas B. (holocron)


Lesenswert?

Hermann Kokoschka schrieb:
> Jonas B. schrieb:
>> Eine auswechselbare Batterie (Knopfzelle) wird allerdings auf
>> jeden Fall benötigt werden.
>
> Erkläre bitte mal warum.
> Wenn Du eh schon kabelgebunden arbeitest...
Meinte mit kabelgebunden, das man ein Kabel (USB-Kabel z.B.) anschließen 
kann, um Daten auf den PC übertragen zu können.

Ben S. schrieb:
> Dein Problem ist asbach. Nimm irgendeinen kleinen 8bit und versetz den
> regelmäßig in Sleep Mode. Oder so ...
Also einfach einen ganz normalen z.B. von atmega mit 8bit?

Danke und Grüße

von Adam P. (adamap)


Lesenswert?

Ich bin grad auch auf der Suche nach einem SoC für unser nächstes 
Projekt (Medizinprodukt) und hab mir auch schon einige Hersteller 
angesehen und dachte dann, ich nehme den nrf52840.

Ziel war es nicht noch extra ein Host µC einsetzen zu müssen.
Platz, Stromverbrauch, usw...

Olaf schrieb:
> Die Toolchain von Nordic erinnert aber immer an Seufzerbruecke in
> Thermomix. :-)

Olaf schrieb:
> Ich hab
> letztens etwas aktuelles von Nordic rausgeworfen weil das einfach nicht
> zu ertragen war.

Doch was meinst du genau bzgl. der SDK, was hat dich gestört oder war 
umständlich?
Mir ist beim Überfliegen aufgefallen, dass man für seine "App" das 
darunterligende System bzgl. Ausführungszeiten und Prio konfigurieren 
muss usw.
Ist es da überhaupt möglich einen stabilen 1ms Zyklus einszustellen?

Dann habe ich noch die gefunden:
https://www.silabs.com/wireless/bluetooth

Aber dort die SoC miteinander zu vergleichen ist ja schon ein Krampf und 
die Übersicht ist nicht sehr vollständig.
Hat mit den jmnd Erfahrung auch bzgl. der SDK?

von Torsten R. (Firma: Torrox.de) (torstenrobitzki)


Lesenswert?

Adam P. schrieb:

> Olaf schrieb:
>> Ich hab
>> letztens etwas aktuelles von Nordic rausgeworfen weil das einfach nicht
>> zu ertragen war.
>
> Doch was meinst du genau bzgl. der SDK, was hat dich gestört oder war
> umständlich?

Die Meinungen sind da durchaus verschieden: 
https://interrupt.memfault.com/blog/the-best-and-worst-mcu-sdks

Ich halte die Dokumentation und das SDK von Nordic auch für sehr gut 
(wenn auch verbesserungswürdig).

Noch mal zum Thema: Bei BLE kannst Du im Peripheral mitbekommen, dass 
sich ein Controller mit dem Peripheral verbunden hat. Entsprechen kannst 
Du versuchen, den Energiebedarf im nicht verbundenen Zustand auf eine 
Minimum herunter zu fahren. 1ms connection Intervall geht mit BLE nicht. 
Das Minimum ist 7,5ms.

von Torsten R. (Firma: Torrox.de) (torstenrobitzki)


Lesenswert?

Jonas B. schrieb:

> Was wäre denn (mit der angeforderten, keinen BLE zu verwenden) ein
> geeigneter µC? Ich hab im Internet hierzu zahllose ultra low power µC
> gefunden, allerdings ist das schwer zu beurteilen (wo die Vor- und
> Nachteile liegen etc.).

Du könntest z.B. trotzdem einen nRF52 nehmen. Eval Boards sind leicht 
verfügbar und kommen mit Knopfzellen-Halterung. Falls Du dann doch noch 
mal BLE verwenden wolltest, dann ist das leicht nachzurüsten.

von ...-. (Gast)


Lesenswert?

Microchip hat viele µC mit XLP im Programm, die brauchen im Sleep 
teilweise deutlich weniger als 1 µA, dann schau Dir noch die 
RN4870/RN4871 an, die brauchen im Shutdown nur knapp 3 µA

von Olaf (Gast)


Lesenswert?

> Doch was meinst du genau bzgl. der SDK, was hat dich gestört oder war
> umständlich?

Ihr SDK unterstuetzt IAR, GCC, Keil. Sie nutzen Makefile, cmake 
(Ninja-mode) und auch die Grafikoberflaeche von Segger. Teilweise wird 
code von Python erzeugt, teilweise Shellscript. Und natuerlich fuer 
Windows und Linux. Das erlaubt eine bemerkenswerte Anzahl von 
Permutationen.
Auserdem haben sie noch einen Schwung tools die aus Scripten bestehen 
die du nur aus ihrer eigenen Anwendung raus starten kannst. (z.B um die 
Firmware da reinzuladen) Auch irgendwie schraeg.

Da kommen schnell viele Fragen auf. Fuer Fragen haben sie ein eigenes 
"betreutes" Forum. Da stehen dann so Sachen wie: "lesen sie mal dies, 
das wird ihnen helfen" Natuerlich mit einem Deadlink weil sie das alle 
drei Monate umorganisieren. Wenn du dann doch mal eine Frage stellst 
passiert erstmal nichts und dann einen Monat spaeter kommt eine 
automatisch generierte Email das du jetzt Profilevel/user irgendwas 
bist.

Alles kein Problem wenn man mit dem Kram ernsthaft entwickelt. Da 
schreibst du ja eh alles neu und liesst vielleicht mal kurz was bei 
denen nach. Aber wenn du nur mal kurz und schnell was evaluieren willst 
um zu entscheiden ob der Controller das Design-In schafft dann ist der 
Aufwand gerade zu absurd.

> Ist es da überhaupt möglich einen stabilen 1ms Zyklus einszustellen?

Genau das willst du dringend evaluieren. .-) Auf den Chips laeuft ja 
auch Software von Nordic die regelmaessig laufen muss damit die 
Funkverbindung nicht abreisst. Du bist nur Nutzer zweiter Klasse im 
System. Da ist jetzt auch nicht negativ gemeint. Anders geht es halt 
nicht. Aber es gibt Grenze die dir da auferlegt.

Olaf

von Schorschi (Gast)


Lesenswert?

Olaf schrieb:
> Genau das willst du dringend evaluieren. .-) Auf den Chips laeuft ja
> auch Software von Nordic die regelmaessig laufen muss damit die
> Funkverbindung nicht abreisst. Du bist nur Nutzer zweiter Klasse im
> System. Da ist jetzt auch nicht negativ gemeint. Anders geht es halt
> nicht. Aber es gibt Grenze die dir da auferlegt.

Jap, da ist das Problem, dass der BLE Stack ziemlich harte Timing 
Anforderungen hat.

Es gäb dann noch der nRF5340, der zwei Kerne hat - einer spezifisch nur 
fürs BLE Handling.

Aber allgemein find ich die nRF-SDK (nicht Connect SDK) ziemlich gut, 
verglichen mit anderen SDKs

von Robin E. (why_me)


Lesenswert?

Mal bei Cypress umgeschaut?
PSoC 4 BLE kann 5V, gibt es als fertige Module und hätte mit capsense 
sogar Hardware integriert um kleine Kapazitäten zu messen (eigentlich 
für Touch Buttons).

von Dieter D. (Firma: Hobbytheoretiker) (dieter_1234)


Lesenswert?

Als break out boards wuerde ich in der Richtung suchen:
XBee & ZigBee mit BLE

von Chris (Gast)


Lesenswert?


von K. H. (hegy)


Lesenswert?

Ergänzend zu der Frage möchte ich meine Erfahrung bzgl. BLE-Controller 
mitteilen.

Chris K. schrieb:
> CC26xx von TI

Ich fand die TI-Doku damals schrecklich und widersprüchlich. Der 
Kollege, der in erster Linie mit dem CC2640 das Bluetooth-Zeug machte, 
fragte sich, wie man bei dem Prozessor Bluetooth überhaupt abschalten 
kann, weil standardmäßig ist Bluetooth aktiv, was aber sehr schlecht ist 
wenn die verwendeten (Folien-)Akkus nur eine Kapazität von 0,5 mAh 
haben.

Chris schrieb:
> STM32WBx5

Die Doku scheint mir wesentlich besser zu sein als die von TI. Wie ich 
finde ist es auch von großem Vorteil, wenn man vorab schon mit STMCube 
den Energieverbrauch feststellen kann. Allerdings bin ich beim STM32WBxx 
noch nicht bis zur Bluetooth-Abteilung vorgedrungen, das kommt vllt. 
nächstes Jahr.

Mit dem nRF-Zeug habe ich keine Erfahrung, da hatte ich als Fall-Back 
nur ein passendes DevKit bestellt, aber hier scheint es evtl. mit am 
einfachsten zu gehen.


Generell Doku oder Kurs über Bluetooth gibt es bei Mohammad Afaneh 
(https://www.novelbits.io/), manches ist gratis, anderes nicht. Hat 
bisher auf mich einen guten Eindruck gemacht, aber bzgl. Bluetooth ist 
bei mir derzeit Pause bis nächstes Jahr wahrscheinlich.

Bitte 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
Noch kein Account? Hier anmelden.