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
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
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.
> 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
State of the art sind im Moment die nRF52 microcontroller von Nordic sowie der Ambiq Apollo 3 (4) von Ambiq Micro.
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.
> 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
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.
Angehängte Dateien:
-
DA14682.JPG
100 KB
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.
> 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
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
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 ...
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...
Danke, kannte ich noch nicht... Die machen ja mal ein paar ausgefallene Dinger...
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
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?
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.
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.
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
> 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
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
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).
Als break out boards wuerde ich in der Richtung suchen: XBee & ZigBee mit BLE
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.
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.