Hi Leute, ich arbeite gerade an einem Projekt und bräuchte euer Fachwissen, um ein paar offene Fragen zu klären. Folgendes Szenario: Ich will mehrere Microcontroller verbauen, die die Sensordaten von jeweils neun Sensoren auslesen und vorverarbeiten. Es handelt sich hierbei um IMUs (Accelerometer, Gyroskop und Magnetometer). Also 3 Sensornodes pro Mikrocontroller. (z2 Mal per I2C und 1 Mal per SPI, da die Sensoren nur auf 2 Adressen einstellbar sind). I2C ist hier wichtig, da ich nur begrenzten Platz für Leitungen habe) Jeder Sensor sendet seine Daten mit einer Auflösung von 16 Bit an den Mikrocontroller. Im Mikrocontroller selbst würde ich die Daten gerne per Kalman- oder Magdwick-Filter vorverarbeiten und in Quaternionen umrechnen. Diese Daten wiederum sollen dann von den Microcontrollern per I2C oder SPI an einen Mastereinheit (nRF52840 - 32bit Prozessor) gesendet werden, die die Daten per Bluetooth an den Rechner sendet. Jetzt zu meinen Fragen: 1. Welcher Microcontroller bietet sich hier denn an? Ich habe an einen 16-bit Microcontroller gedacht, da die Verarbeitung der Daten möglichst schnell gehen soll. Die Abtastfrequenz der Sensoren soll möglichst hoch sein. Zuerst wollte ich einen Microcontroller mit 2 I2C Schnittstellen, so dass dieser gleichzeitig als Slave und Master arbeiten kann. Theoretisch könnte man eine Schnittstelle auch softwareseitig lösen. Allerdings bin ich mir nicht sicher mit welchen Frequenzen ich hierbei arbeiten kann. Was würdet ihr hier empfehlen? Habt ihr vielleicht einen speziellen Microcontroller im Sinn, der ausreichend Rechenleistung hat, um die Vorverarbeitung möglichst schnell zu bewerkstelligen? 2. Der I2C Standard hat sieht ja 8 Bit Registeradressen und Daten vor. Wie kann ich per I2C 16 Bit Adressen und Daten auslesen 3. Ich bin mir auch noch nicht genau sicher, wie die Firmware im Microcontroller auszusehen hat. Grundsätzlich lese ich meine Daten aus den Sensoren und verarbeite diese. Die verarbeiteten Daten, werden dann von meinem Mastercontroller abgefragt. Lege ich diese Daten dann am Besten immer unter derselben Adresse ab, die der Master dann per I2C abfrägt oder wie würde der Code hier ungefähr aussehen? Der grundsätzliche Aufbau ist mir bereits klar. Aber es gibt noch diese offenen Fragen, bei denen ich mir noch nicht wirklich sicher bin, wie man das am elegantesten lösen könnte.
Wegen der Vorverarbeitung der Daten würde ich dafür einen Raspberry nehmen. Dessen Stärke liegt in der komplexeren Verarbeitung von Daten. Für mehr hardwarenahe Aufgaben mit Schalterabfrage, Relaisansteuerung usw. wäre ein Arduino besser geeignet. Da gibt es dann noch verwandete Ableitungen wie ESP32 mit Möglichkeiten der drahtlosen Datenübertragung.
Günni schrieb: > Wegen der Vorverarbeitung der Daten würde ich dafür einen Raspberry > nehmen. Dessen Stärke liegt in der komplexeren Verarbeitung von Daten. > > Für mehr hardwarenahe Aufgaben mit Schalterabfrage, Relaisansteuerung > usw. wäre ein Arduino besser geeignet. Da gibt es dann noch verwandete > Ableitungen wie ESP32 mit Möglichkeiten der drahtlosen Datenübertragung. Raspberry ist leider aufgrund des begrenzten Platzes nicht möglich. Habe aber auch schon an einen STM32 gedacht, da deutlich mehr Leistung als 8/16 Bit Controller und zudem gibt es auch Ausführungen mit 2 I2C Schnittstellen. Entsprechend würde ich mir hier den Aufwand ersparen, die zweite I2C Schnittstelle per Software zu implementieren. Welche Ausführung würde sich denn eigenen? Pins brauche ich abgesehen von den beiden I2C Schnittstellen keine.
Christian H. schrieb: > Raspberry dafür völlig oversized. Ein OS braucht man dafür wirklich nicht. Christian H. schrieb: > STM32 Schon besser oder LPC. Einen 16Bit uC würde ich dafür nicht mehr einsetzen. Schau Dir doch mal die Bluepills (STM32F103) oder Blackpills (STM32F411 mit FPU) an. Die gibt es günstig und zum testen ist schon alles drauf. Wenn es dann passt und zu groß ist, kannst Du Dir immer noch den uC einzeln kaufen und auf Dein Board pflanzen. STM hat übrigens eine parametrische Suche.
:
Bearbeitet durch User
Moin, - bei den STM32-Familie koenntest Du auf die STM32F411 gucken: drei I2C-Anschluesse, die Berechnungen koennen in Hardware-Float (single Prec) gamacht werden. Wenn Du mehr Rechenleistung brauchst, koenntest Du um die H-Familie kuemmern, hardware Double Prec. Aber Du solltest Dir erstmal gedanken machen, welche Datenraten und Aufloesungen Deine Sensoren liefern koennen (Hint: 16bit Aufloesung ist nie trivial). Weisst Du schon, welche Sensoren Du benutzen willst? Viele Gruesse Th.
Christian H. schrieb: > Was würdet ihr hier empfehlen? Habt ihr vielleicht einen speziellen > Microcontroller im Sinn, der ausreichend Rechenleistung hat, um die > Vorverarbeitung möglichst schnell zu bewerkstelligen? So eine grenzdebile Spzifikation haut dem Fass den Boden aus. JEDER µc hat ausreichend Rechenleistung, um jegliche Datenverarbeitung "möglichst" schnell zu erledigen. "Möglichst" bedeutet nämlich: im Rahmen seiner Möglichkeiten. Da jeder µC im Rahmen seiner Möglichkeiten rechnen kann, ist die Anforderung also immer erfüllt. Wenn "möglichst" aber bedeuten soll "schnellstmöglich in globaler Betrachtung", dann erfüllt natürlich nur genau ein µC die Anforderung: der schnellste, den der Markt hergibt. Aber: wer solche schwachsinnigen Spezifikationen verbricht, ist sowieso nicht in der Lage, so ein Dickschiff zu programmieren...
Christian H. schrieb: > Ich habe an einen 16-bit Microcontroller gedacht, da die Verarbeitung > der Daten möglichst schnell gehen soll. Die Abtastfrequenz der > Sensoren soll möglichst hoch sein. Um "möglichst schnell" und "möglichst hoch" zu realisieren, solltest du überlegen, wo dein Flaschenhals bei der Erfassung/Verarbeitung liegt. Mit einem speziell für die Aufgabe maßgeschneiderten µC lässt sich das dann sicher umsetzen. Erfahrungsgemäß ist so eine Vorgehensweise meist allerding durch das verfügbare Budget limitiert ;-)
c-hater schrieb: > Aber: wer solche schwachsinnigen Spezifikationen verbricht, ist sowieso > nicht in der Lage, so ein Dickschiff zu programmieren... Ich fürchte du sprichst hier ein ganz wahres Wort gelassen aus. Christian H. schrieb: > 2. Der I2C Standard hat sieht ja 8 Bit Registeradressen und Daten vor. > Wie kann ich per I2C 16 Bit Adressen und Daten auslesen Keine Ahnung von nichts. Christian H. schrieb: > 3. Ich bin mir auch noch nicht genau sicher, wie die Firmware im > Microcontroller auszusehen hat. Ja, aber schon fast fertig, gell? Christian H. schrieb: > Lege ich diese Daten dann am Besten immer unter derselben Adresse ab, > die der Master dann per I2C abfrägt oder wie würde der Code hier > ungefähr aussehen? Wir sollen dir jetzt den Arduino-Sketch liefern? Christian H. schrieb: > ich arbeite gerade an einem Projekt und bräuchte euer Fachwissen, um ein > paar offene Fragen zu klären. Paar wenige offene Fragen? ROFL
c-hater schrieb: > Christian H. schrieb: > >> Was würdet ihr hier empfehlen? Habt ihr vielleicht einen speziellen >> Microcontroller im Sinn, der ausreichend Rechenleistung hat, um die >> Vorverarbeitung möglichst schnell zu bewerkstelligen? > > So eine grenzdebile Spzifikation haut dem Fass den Boden aus. JEDER µc > hat ausreichend Rechenleistung, um jegliche Datenverarbeitung > "möglichst" schnell zu erledigen. "Möglichst" bedeutet nämlich: im > Rahmen seiner Möglichkeiten. Da jeder µC im Rahmen seiner Möglichkeiten > rechnen kann, ist die Anforderung also immer erfüllt. > > Wenn "möglichst" aber bedeuten soll "schnellstmöglich in globaler > Betrachtung", dann erfüllt natürlich nur genau ein µC die Anforderung: > der schnellste, den der Markt hergibt. > > Aber: wer solche schwachsinnigen Spezifikationen verbricht, ist sowieso > nicht in der Lage, so ein Dickschiff zu programmieren... Danke für deine hilfreiche Antwort. Vielleicht solltest du mal wieder an die frische Luft. Der Lockdown scheint dir etwas zuzusetzen. Hatte eigentlich erwartet hier auf etwas freundlichere Unterstützung zu treffen. Da von dir aber auch keine weitere Hilfe zu erwarten ist, werde ich aber auch nicht weiter auf deine Antwort eingehen. Trotzdem danke für deinen Beitrag. Thomas W. schrieb: > Aber Du solltest Dir erstmal gedanken machen, welche Datenraten und > Aufloesungen Deine Sensoren liefern koennen (Hint: 16bit Aufloesung ist > nie trivial). Danke für deine Antwort. Ich hab mir mal ein paar Paper zu vergleichbaren Projekten angesehen. Dort wird weitestgehend mit 100 Hz abgetastet. Da in meinem Projekt aber deutlich anspruchsvollere und schnellere Bewegungen getrackt werden sollen, würde ich auch gerne mit höheren Abtastraten arbeiten. Das Gyroskop kann hierbei bis zu 6.4 kHz, das Accelerometer 1,6kHz und und Magnetometer bis zu 300 Hz abtasten. Versuchen würde ich gerne mindestens 500 Hz bei Gyroskop und Accelerometer zu verarbeiten. Das entspräche 2 ms. Also sollte der Algorithmus unter 2 Millisekunden benötigen, um die Berechnungen auszuführen und an den Master weiterzuleiten. Was meinst du damit, dass 16bit Auflösungen nie trivial sind? Meinst du die Verarbeitung der Daten oder die Kommunikation zwischen Sensoren und dem Mikrocontroller? Bosch Sensortec stellt per Git bereis APIs zur Verfügung mit denen ich die Daten aus den Sensorregistern auslesen kann. Lediglich die Kommunikation zwischen Mikrocontroller und Master ist mir noch nicht ganz klar. Bzw. wie die beiden Firmwares auszusehen haben bzgl. Speicherzugriffen und dem Kommunikationsprotokoll. Thomas W. schrieb: > Weisst Du schon, welche Sensoren Du benutzen willst? Die Sensoren werden von Bosch Sensortec bereitgestellt -> BMI270 (IMU), BMM150 (Magnetometer) und gegebenfalls noch ein BMP388 (Drucksensor)
Christian H. schrieb: > Im Mikrocontroller selbst würde ich die Daten gerne per Kalman- oder > Magdwick-Filter vorverarbeiten und in Quaternionen umrechnen. So eine Kalmanfilterung benötigt schon einiges an Rechenleistung. Etwa 1990 kamen erste GPS-Empfänger auf den Markt. Während für "normale" Regler und PersonalComputer damals 8-Bit-Prozessoren üblich waren und ausreichten, hatten die Empfänger CPUs der 68000-er Familie oder ähnlich leistungsfähige CPUs. Deshalb war ich auf den Raspi gekommen.
Christian H. schrieb: > Danke für deine hilfreiche Antwort. Vielleicht solltest du mal wieder an > die frische Luft. War ich gerade (Wochenendeinkauf). > Hatte eigentlich erwartet hier auf etwas freundlichere Unterstützung zu > treffen. Wie sagt man einem Idioten freundlich, dass er ein Idiot ist? Mach' einen Vorschlag! > Da von dir aber auch keine weitere Hilfe zu erwarten ist, werde ich aber > auch nicht weiter auf deine Antwort eingehen. Das solltest du aber. Auch andere Leute können nur wirklich hilfreiche Antworten geben, wenn die Spezifikation sinnvoll ist. Die bisherige läßt halt je nach Interpretation nur zwei Tipps zu, entweder ist jeder beliebige µC gut genug oder es muss der schnellste sein, den man für Geld kaufen kann. Du müsstest also schonmal im Minimum die gewünschte Interpretation deiner "Spezifikation" klarstellen.
Christian H. schrieb: > Lediglich die Kommunikation zwischen Mikrocontroller und Master ist mir > noch nicht ganz klar. Sag es doch direkt: Du hast noch keinen Schimmer, wie man das hin kriegt ;-) Günni schrieb: > So eine Kalmanfilterung benötigt schon einiges an Rechenleistung. Wie rechenaufwändig ein Kalman-Filter wird, hängt sehr davon ab, was genau gerechnet werden soll. Das kann alles von einem 3-Zeiler bis zu aufwändiger Systemsimulation und Matrizenrechnung sein. Christian H. schrieb: > (z2 Mal per I2C und 1 Mal per > SPI, da die Sensoren nur auf 2 Adressen einstellbar sind). Es gibt I2C Multiplexer mit denen du durch Busumschaltung unabhängig von den möglichen Sensoradressen wirst.
c-hater schrieb: > Das solltest du aber. Auch andere Leute können nur wirklich hilfreiche > Antworten geben, wenn die Spezifikation sinnvoll ist. Die bisherige läßt > halt je nach Interpretation nur zwei Tipps zu, entweder ist jeder > beliebige µC gut genug oder es muss der schnellste sein, den man für > Geld kaufen kann. > > Du müsstest also schonmal im Minimum die gewünschte Interpretation > deiner "Spezifikation" klarstellen. Dann präzisiere ich gerne nochmal die Aufgabenstellung: Es handelt sich hierbei um meine Abschlussarbeit. Ziel ist die Erarbeitung einer Datenpipeline von den Sensoren bis zum Rechner. Es existiert bereits ein Prototyp, dessen Sensorknoten alle mit einem Mikrocontroller ausgestattet sind und der die Daten per Bluetooth an den Rechner bzw. das Handy sendet. Davon will mal in meiner Aufgabenstellung aber weg, da die Sensorknoten kleiner gestaltet werden sollen (nur aus den Sensoren bestehend). Das heißt, dass ich diese per I2C gerne auslesen würde. Da alle Sensoren von Bosch Sensortec lediglich zwei Adressen per I2C zulassen, will ich die Mikrocontroller vorschalten, damit ich unabhängige Cluster erhalte und so mit den Adressen klarkomme. Ein I2C Multiplexer fällt leider raus, da ich hierfür zu viele Leitungen benötigen würde. Da alle Daten über eine Bluetooth Einheit weitergeleitet werden soll, möchte ich versuchen die Daten in den Mikrocontrollern vorzuverarbeiten, dass ich auch hier per I2C kommunizieren kann. Ohne Vorverarbeitung würden die 400 kHz nicht ausreichen (Fast Mode des nRF52840), da insgesamt 9 Sensoreinheiten verbaut werden sollen (10 DOF) Daher war die Idee, direkt eine Kalman Filterung in den Mikrocontrollern vorzunehmen. Natürlich muss ich hier noch evaluieren, ob das überhaupt machbar ist, oder ob ich die Rohdaten einfacher verarbeiten kann und die Filterung später auf dem Rechner ausführe. Ich stehe noch direkt am Anfang der Arbeit und hab mich auch noch nicht in alle Spezifikationen eingelesen. Das sind eben die Probleme, bei denen ich derzeit nicht weiß wie man sie effizient lösen würde und mir gerne Rat von erfahrenen Leuten geholt hätte. Wenn du nun noch weitere Fragen hast, beantworte ich dir diese gerne.
Christian H. schrieb: > Dann präzisiere ich gerne nochmal die Aufgabenstellung: [...] Du musst noch sehr viel lernen. Das ganze Geschwalle trägt nämlich rein garnix zur Konkretisierung der Anforderungen bei.
Christian H. schrieb: > Habe aber auch schon an einen STM32 gedacht, da deutlich mehr > Leistung als 8/16 Bit Controller und zudem gibt es auch Ausführungen > mit 2 I2C Schnittstellen. Andreas B. schrieb: > STM hat übrigens eine parametrische Suche. Die nützt nur nicht viel, weil die meisten Typen nicht lieferbar sind. Ich dachte eben, ich schlage mal eine Hand voll vor -- das ist das Ergebnis: STM32L412CBT6 -- 3 I2C, 2 SPI, 2 UART, Cortex-M4F, 40KB RAM im 7x7mm-Gehäuse und lieferbar. Wolfgang schrieb: > Christian H. schrieb: >> (z2 Mal per I2C und 1 Mal per >> SPI, da die Sensoren nur auf 2 Adressen einstellbar sind). > > Es gibt I2C Multiplexer mit denen du durch Busumschaltung unabhängig von > den möglichen Sensoradressen wirst. Manche Chips lesen ihre Adresspins nur nach einem Reset, manche bei jedem I2C-Start. Bei letzteren kann man einen Adresspin per GPIO ansteuern und quasi wie einen SPI-Chipselect benutzen.
c-hater schrieb: > Du musst noch sehr viel lernen. Das ganze Geschwalle trägt nämlich rein > garnix zur Konkretisierung der Anforderungen bei. Für Leute, die wie ich, mit solchen Sensoren schon mal gearbeitet haben, waren die Angaben schon brauchbar und für eine gezielte Antwort ausreichend. Das gilt auch für: Wolfgang schrieb: > Wie rechenaufwändig ein Kalman-Filter wird, hängt sehr davon ab, was > genau gerechnet werden soll. Das kann alles von einem 3-Zeiler bis zu > aufwändiger Systemsimulation und Matrizenrechnung sein. Wenn Bewegungen mit Sensoren erfasst und verarbeitet werden sollen, wird die Filterung ziemlich aufwändig. Deshalb auch mein Hinweis auf die Kalman-Filterung in GPS-Empfängern. Bei anderen Anwendungsgebieten sieht das natürlich anders aus. Aber eventuell wäre eine andere Art der Komprimierung einfacher und würde weniger Rechenleistung bei den Knotenprozessoren erfordern. (Z.B. indem wie bei der Differenz-Puls-Code-Modulation nur Differenzen zum vorangegangenen Wert übertragen werden, die weniger Stellen benötigen. Da dort durch verringerte Bitlänge Rundungsfehler auftreten, müsste der Fehler in den nächsten Wert zurückgeführt und dort korrigiert werden. So etwas machte man, als die Rechenleistung bei Bildübertragungen für eine Transformation noch nicht ausreichte.)
Günni schrieb: > Wenn Bewegungen mit Sensoren erfasst und verarbeitet werden sollen, wird > die Filterung ziemlich aufwändig. Noch so ein Idiot, der nicht in der Lage ist, die Anforderungen in Zahlen zu fassen. Als Mensch vielleicht OK, als Entwickler hingegen unbrauchbarer Müll.
Christian H. schrieb: > Ein I2C Multiplexer fällt leider raus, da ich hierfür zu viele Leitungen > benötigen würde. Wieso? Schon mal einen PCA9547 verwendet? https://www.nxp.com/docs/en/data-sheet/PCA9547.pdf Da geht die Umschaltung bzw die Auswahl des Kanals auch über I2C. Die 3 Adresspins sind nur zur Festlegung der I2C-Adresse des Multiplexers da. Dh. 3 (SCL/SDA/INT) Signale rein, 8*3 Signale raus. fchk
So, wie ich dich verstehe, willst du dich eher nicht mit den Details des Mikrocontrollers auseinandersetzen müssen (Abschlussarbeit bedeutet ja, sich auf das Wesentliche konzentrieren zu müssen). Du brauchst eine Umgebung, die dir die HW-nahe Detailarbeit "abnimmt", so dass Du möglichst high-level programmieren kannst. Sicher wäre Raspy oder Arduino bedenkenswert. Beites leistet genau das: Den Entwickler von Details der HW entlasten. Empfehlen würde ich aber auch die Produkte von Infineon und Cypress: XMC-Mikrocontroller mit der Dave-4 Entwicklungsumgebung, resp. Cypres PSoc-Kontroller mit PSoc-Creator. Beides sind ARM-Kontroller (M0 oder M4), die vermutlich deinen Anforderungen vollauf genügen. Es gibt eine ganze Reihe von günstigen Entwicklungsboards. Beide IDEs (Dave und PSoc-Creator) sind kostenlos verfügbar und ermöglichen extrem effizientes Arbeiten.
> willst du dich eher nicht mit den Details des > Mikrocontrollers auseinandersetzen müssen (Abschlussarbeit bedeutet ja, > sich auf das Wesentliche konzentrieren zu müssen) Unsinn. Die Gesamtheit aller Details ist die Abschlussarbeit.
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.