Beschleunigungssensor (MMA8451) - Suche Hilfe bei Integration und Beispiele

maximweb · 28. August 2025 um 19:42

Hallo zusammen,

ich bin ganz frisch zu Espuino gekommen und bin jetzt schon begeistert, denke aber auch schon über Erweiterungen nach. Und zwar konkret einen Beschleunigungssensor für Bewegungssteuerung.

Kurzfassung: Hat jemand hier vielleicht Erfahrungsberichte mit verschiedenen Sensoren und Beispiele für die Code-Integration?

Ich hab im Forum gestöbert und bisher zwar ein paar wenige Absichtserklärungen gefunden, aber wenig zur konkreten Umsetzung:

Das scheinen auch die gängigsten günstigen Beschleunigungssensoren zu sein. Bei der Recherche ist mir jedoch noch ein anderer Kandidat aufgefallen MMA8451 gibts auf einem Breakout-Board von Adafruit.

Der ist zwar etwas teurer, aber ich möchte dem Devboard so wenig wie möglich mehr Berechnungen zumuten. Soweit ich das überblicke hat:

ADXL345
- Single/double tap detection
- Activity detection
- Freefall detection
- 32-Messungen FIFO Speicher
MPU-6050
- Tap detection
- orientation detection
- “high-g” interrupt
- zusätzlich Gyroskop
- low-pass Filter, ev. nur für Gyroskop?
- 1024-byte FIFO Speicher (mit deaktiviertem Gyro und 2 Byte je Achse vom Accelerometer müssten das 170 Messungen sein, falls man das entsprechend konfigurieren kann)
MMA8451
- Single/double tap detection (pulse)
- Freefall/motion detection
- Transient detection (mit high-pass Filter!)
- Orientation detection
- 32 Messungen FIFO Speicher

Alle sind per I2C anbindbar, was das mini4L ja erfreulicherweise zur Verfügung stellt.

Der MMA8451 hat in meinen Augen also das Potential am wenigsten Rechenleistung vom ESP32 zu brauchen, da mehr interne Detektionsmöglichkeiten vorhanden sind. Der größere Speicher von MPU-6050 scheint mir nur dann nützlich, wenn doch Postprocessing von Events auf dem ESP32 stattfinden soll, was ich so gut es geht vermeiden/reduzieren möchte.

Kurzum: Ich hab mir den MMA8451 besorgt, die Beispielbibliothek kurz angeschaut und bereits angefangen meine eigene Library zu schreiben.

Mir schweben folgende Funktionen vor. Ob ich die final alle einbaue und wie viel Feintuning die benötigen weiß ich noch nicht:

Kippen erkennen: Funktioniert bereits in meiner Library und scheint recht zuverlässig zu sein.
Single/double Tap von allen 6 Seiten: Funktioniert prinzipiell, aber insbesondere wenn mehr als eine Achse aktiviert wurde, gibt es häufiger False-Positives. Da werde ich wahrscheinlich nicht umhin kommen die 32 letzten Messwerte des Events auszulesen um Falscherkennungen auszusortieren.
Schütteln: Hierfür hab ich die “Transient detection” mit high-pass Filter angezapft. Events werden mir aber etwas zu häufig getriggert. Hier würds aber wahrscheinlich reichen eine Logik ähnlich wie beim Button-Longpress einzubauen: Tritt das Event innerhalb von 0,x Sekunden wiederholt auf?

Jetzt stellen sich mir einige Fragen, wie ich weitermachen könnte:

Hardware

Ich habe hier gelesen, dass die Stromversorgung des I2C eventuell Probleme machen könnte. Und hier, dass der JP6 seit rev3.1 nicht mehr existiert.
Wie ist denn da der aktuelle Stand?
Idealerweise würde ich mir gerne zumindest einen der Interrput-Pins des MMA8451 zu Nutzen machen. Kann ich dafür einen der GPIOs auf EXT verwenden, oder gibts da Restriktionen zu beachten?

Software

Meine Idealvorstellung wäre hier, dass ich den Sensor derart einbinde, dass ich verschiedene Funktionen über das Button-Layout konfigurieren kann. Ich stehe aber noch ganz am Anfang die Struktur des Codes zu verstehen.

Irgendwelche Hinweise wo ich da ansetze?

Ich vermute mal, dass ich das Konfigurieren und Starten des Sensors in Power_PeripheralOn und den DeepSleep (zum Stromsparen) in Power_PeripheralOff packen muss?
Und dann irgend eine Accelerometer_Cyclic() meiner Library in main() für die eigentliche Verarbeitung?
Irgendwie noch nicht gefunden habe ich, wo typischerweise die Interrupts konfiguriert werden? Macht das jede Library selbst?
Und auch beim Button-Layout bin ich noch nicht durchgestiegen wie da ein Ergänzen weiterer pseudo Buttons zu integrieren wären.

Vielen Dank schonmal für die Hilfe und das Durchhalten beim Lesen meines Romans .

PS: Die Library stelle ich dann natürlich gerne zur Verfügung, noch ist sie aber sehr explorativ und mit vielen hart codierten Einstellungen.

biologist · 28. August 2025 um 20:33

Wir schalten (traditionell) bei Dingen wie SD-Reader, Neopixel und MAX98357a die Spannungsversorgung im Deepsleep des ESP32 weg. Beim Port-Expander, der per i2c angebunden ist, wird das nicht gemacht, da man den ja zum Aufwecken braucht. Problem: Beim ext. Konnektor für i2c hatte ich am Anfang die Spannungsversorgung ebenfalls mit abgeschaltet. Das ist insofern doof, weil wenn da was dranhängt, dann zieht das im Deepsleep den i2c-Bus runter und der funktioniert dann nicht mehr gescheit. Ergo: Der ESP32 wacht dann nicht mehr auf, da der Port-Expander nicht richtig arbeitet. Ich bin dann iwann hingegangen und habe das jumperbar gemacht. D.h. man konnte wählen, ob die Spannungsversorgung des i2c ext. permanent ist oder ob sie abgeschaltet wird im Deepsleep. Es kam dann der Wunsch auf, dass der i2c-Konnektor erweitert wird, so dass man nicht mehr wählen muss. Also habe ich den Konnektor um einen Pin erweitert und damit konnte der Lötjumper entfallen. Das war auch der letzte Stand. D.h. da gibts 3.3v, 3.3v switched, gnd, scl und sda.

Ansonsten: GPIO32 eignet sich auch für Interrupts

Die Idee kam schon 2-3 mal auf. Ob es jmd. für sich privat umgesetzt (geforkt) hat weiß ich nicht. Aber der Grund, weswegen das von mir nie supported wurde oder gar den Weg in mein Repository gefunden hat, ist, dass ich NICHT das Benutzungskonzept der bekannten Box, die man käuflich erwerben kann, kopieren möchte. Ich vermeide jegliche namentliche und konzeptionelle Nähe (außer RFID) und vermeide auch extra den Namen der Box, da ich nicht im Fahrwasser dieser Box mitschwimmen möchte und nicht mal im Ansatz mit irgendwem Ärger haben möchte. Insofern werde ich, auch in Zukunft, dieses Bedienungskonzept nicht unterstützen.