Hi liebe Forenmitglieder, Ich habe eine Verständnisfrage zu I2C, die mir Google nicht richtig beantworten konnte. Und zwar arbeite ich momentan an einem Sensor, um Bewegungen zu tracken. Hierzu habe ich einen Arduino Due (84 MHz), der mehrere IMUs, Magnetometer und Drucksensor per I2C auslesen soll. Die unterstütze Geschwindigkeiten der Sensoren liegt bei 400 kBit/s. Die IMU soll mindestens mit einer Abtastrate von 1 kHz arbeiten. Die anderen beiden Sensoren tasten weniger häufig ab und können für das Verständnis zunächst mal ignoriert werden. Bei einer Genauigkeit von 16 Bit komm ich so rein rechnerisch auf eine Datenrate von: 1 kHz 16 Bit (3 + 3) = 144 kBit/s Wenn ich nun jeweils zwei der Sensoren an den Bus hänge, komme ich auf dann auf 288 kBit/s reine Daten (Overhead durch das Übertragen der Adresse und der auszulesenden Register noch nicht ein errechnet. Das heißt, dass ich an diesen Bus erstmal keine Sensoren mehr hängen kann, da sonst die maximale Datenrate überschritten wird und mir deshalb Messungen verloren gehen würden -> es fallen mehr Daten an, als Ausgelesen werden können). Jetzt zu meiner Verständnisfrage: Der Due verfügt ja über zwei I2C Schnittstellen und bei einer Taktfrequenz von 84 MHz ist der Due ja eigentlich noch lange nicht ausgelastet. Lediglich der I2C Bus. Ist es deshalb möglich an die zweite Schnittstelle weitere zwei Sensoren zu hängen? Rein vom Verständnis würde ich zunächst mal annehmen, dass es nicht funktioniert, da der Arduino ja während des Auslesens in der Wire-Library hängt und die Dauer eben von der Frequenz des Busses und nicht von der des Due abhängt. Ich hoffe ich konnte mein Fragestellung verständlich genug erklären. Danke für eure Hilfe
Christian H. schrieb: > Rein vom Verständnis würde ich zunächst mal annehmen, dass es nicht > funktioniert, da der Arduino ja während des Auslesens in der > Wire-Library hängt und die Dauer eben von der Frequenz des Busses und > nicht von der des Due abhängt. Am besten würde es funtkionieren, wenn du deine I²C Peripherie mit DMA (PDC) betreibst. Weiß aber spontan nicht, inwieweit es da unterstützende Arduino Libs gibt. Anscheinend musst du für den zweiten I²C einfach die Klasse "Wire1" nutzen. Was jedoch noch nicht dein "hängen bleiben" löst. Also in der Wire Lib sind Callbacks vorhanden und hab beim überfliegen auch PDC source gesehen - habe ich jedoch beim Arduino nie verwendet. Könntest du dein System nicht mit SPI aufbauen, das würde deine Timing-Probleme lösen, wenn du "viele" Sensoren hast.
:
Bearbeitet durch User
>Die IMU
kann die 1kHZ?
reichen villeicht auch 10Hz oder 1Hz?
Christian H. schrieb: > Bei einer Genauigkeit von 16 Bit Du meinst Auflösung, siehe Auflösung und Genauigkeit. > komm ich so rein rechnerisch auf eine > Datenrate von: > 1 kHz 16 Bit (3 + 3) = 144 kBit/s Deine Formel wurde durch die halbschlaue Automatik zerstückelt. Meintest du
1 | 1 kHz * 16 Bit * (3 + 3) = 144 kBit/s |
Was sind die 3+3? 6 Register aus den IMU? Was sind die IMU? Trägheitsnavigation? > Ist es deshalb möglich an die zweite Schnittstelle weitere zwei Sensoren > zu hängen? Ja. > Rein vom Verständnis würde ich zunächst mal annehmen, dass es nicht > funktioniert, da der Arduino ja während des Auslesens in der > Wire-Library hängt und die Dauer eben von der Frequenz des Busses und > nicht von der des Due abhängt. Das ist eine andere Frage. Aber einen I2C-Bus dermaßen nahe seiner Buskapazität zu betreiben und nebenbei noch ausreichend CPU-Zeit zu haben ist nicht trivial. Ich glaube, damit ist die Wire-Lib des Arduino überfordert, denn die arbeiten blockierend und nicht interruptgesteuert. Wenn man das so machen will, muss man eine eigene Lösung von der Pike auf erarbeiten. Aber auch das ist, vor allem mit 2 I2C Bussen, nicht ganz trivial. Dazu braucht es Interrupts und Statemachines. DMA kann helfen, ist aber nicht zwingend.
Adam P. schrieb: > Könntest du dein System nicht mit SPI aufbauen, das würde deine > Timing-Probleme lösen, wenn du "viele" Sensoren hast. I2C wäre besser geeignet, da der Leitungsaufwand so gering wie möglich gehalten werden muss und Kreuzung vermieden werden müssen (Leitungen sollen auf einem Textil vernäht werden). dummschwaetzer schrieb: > kann die 1kHZ? > reichen villeicht auch 10Hz oder 1Hz? Die IMU kann sogar 1,6 kHZ für das Accelerometer und 6,4 kHz für das Gyroskop. 1 kHz sind Mindestanforderung. Falk B. schrieb: > Du meinst Auflösung, siehe Auflösung und Genauigkeit. Ja. Natürlich meinte ich die Auflösung. Falk B. schrieb: > Was sind die 3+3? 6 Register aus den IMU? Was sind die IMU? > Trägheitsnavigation? Die 3+3 sind die Freiheitsgrade der IMU -> 3D für das Accelerometer und 3D für das Gyroskop. Falk B. schrieb: > Das ist eine andere Frage. Aber einen I2C-Bus dermaßen nahe seiner > Buskapazität zu betreiben und nebenbei noch ausreichend CPU-Zeit zu > haben ist nicht trivial. Ich glaube, damit ist die Wire-Lib des Arduino > überfordert, denn die arbeiten blockierend und nicht interruptgesteuert. > > Wenn man das so machen will, muss man eine eigene Lösung von der Pike > auf erarbeiten. Aber auch das ist, vor allem mit 2 I2C Bussen, nicht > ganz trivial. Dazu braucht es Interrupts und Statemachines. > DMA kann helfen, ist aber nicht zwingend. Adam P. schrieb: > Am besten würde es funtkionieren, wenn du deine I²C Peripherie mit DMA > (PDC) betreibst. > Weiß aber spontan nicht, inwieweit es da unterstützende Arduino Libs > gibt. > > Anscheinend musst du für den zweiten I²C einfach die Klasse "Wire1" > nutzen. > Was jedoch noch nicht dein "hängen bleiben" löst. > > Also in der Wire Lib sind Callbacks vorhanden und hab beim überfliegen > auch PDC source gesehen - habe ich jedoch beim Arduino nie verwendet. Danke Adam und Falk. Das bestätigt mir, was ich mir bereits dachte. Ein dritter Sensor soll noch per SPI direkt am Mikrocontroller betrieben werden. Wenn ich die Zeit dafür hochrechne, ist der Due fast ausschließlich mit dem Auslesen der Daten beschäftigt und es bleibt keine Zeit mehr für weitere Verarbeitungsschritte. Habe mich deshalb mal in die DMA Thematik eingelesen und das klingt zumindest mal sehr vielversprechend. So würde ich die Auslastung der CPU extrem verringern und könnte gegebenenfalls zwei weitere Sensoren an dem zweiten I2C-Interface betreiben (oder mit einem Multiplexer am gleichen Interface arbeiten [Adressraum der IMU ist auf zwei Adressen beschränkt]). Da das System später sowieso nicht auf dem Due, sondern auf einem NINA-B3 (basiert auf einem NRF52840) laufen soll, werde ich wohl direkt auf dem Zielcontroller arbeiten, da hier die I2C-Lib wohl DMA unterstützt (https://infocenter.nordicsemi.com/index.jsp?topic=%2Fps_nrf52840%2Ftwim.html)
Christian H. schrieb: > Wenn ich nun jeweils zwei der Sensoren an den Bus hänge, komme ich auf > dann auf 288 kBit/s reine Daten (Overhead durch das Übertragen der > Adresse und der auszulesenden Register noch nicht ein errechnet. Letztendlich wirst du für jede IMU einen I2C-Hardwarekanal brauchen, was die Anforderung „mehrere“ IMUs bei 1khz Abtastrate auf die Anzahl eben jener I2C-Kanäle beschränkt. Die I2C-Module laufen dann allerdings fast von alleine vor sich hin, da musst du eigentlich nur die Adressen vorgeben und dann die angelieferten Bytes abholen. Dafür braucht’s kein DMA, das schafft der Prozessor auch so. Oliver
:
Bearbeitet durch User
Oliver S. schrieb: > Letztendlich wirst du für jede IMU einen I2C-Hardwarekanal brauchen, was > die Anforderung „mehrere“ IMUs bei 1khz Abtastrate auf die Anzahl eben > jener I2C-Kanäle beschränkt. Die I2C-Module laufen dann allerdings fast > von alleine vor sich hin, da musst du eigentlich nur die Adressen > vorgeben und dann die angelieferten Bytes abholen. Dafür braucht’s kein > DMA, das schafft der Prozessor auch so. Ist der Prozessor dann aber nicht zu rund 70% nur mit dem Auslesen der Daten beschäftigt?
(Auch hier wird der Overhead und das Auslesen der anderen beiden Sensoren noch nicht betrachtet) => Vermutlich liege ich eher bei einer Auslastung von 90% An welchem I2C-Kanal ich die Sensoren betreibe, wäre ja grundsätzlich egal, da der Prozessor während dem Auslesen blockiert wird.
:
Bearbeitet durch User
Ihr dürft mich jetzt für das Folgende Teeren und Federn;-) Wenn ich die Intention von Philips für die Existenz des I2C Prinzips richtig verstehe, wurde gerade dieser Bus nur für die einfache Zusammenschaltung von einfachen Peripherie ICs auf einzelnen Leiterplatten zur Verdrahtungsvereinfachung konzipiert. Also ICs die irgend etwas eine Zeitlang machen müssen ohne andauernd Daten zu übertragen. Ich denke da hauptsächlich an die damaligen Peripherie Einheiten wie RTCs, PLL, IO-Expander u.ae. wie man sie in den damaligen Consumergeräten wie TVs, VCR, Funkgeräte vorfand. Der PLL Steuer IC wurde nur beim Kanalwechsel angesprochen und brauchte dann für lange Zeit keine weitere Interaktion. Das nur als geschichtlicher Hintergrund. Wenn man Frequenzhuepfende PLL- Funkgeräte mal absieht die dann wahrscheinlich auch SPI hatten.. Heute findet man ICs wie jene die hier besprochen werden. Ich bin ketzerischerweise der Meinung, dass das eine ungünstige HW Loesung ist und man besser auf das einfachere und schnellere SPI ausweichen sollte. Sogar ein AVR mit 16Mhz kann pro Byte mit 1us/Byte auskommen (8MHz Baudrate) und viele uC können da bis an die Grenze der SPI Peripherie ICs konfiguriert werden. Deshalb schlage ich vor I2c nur für die langsamen Busteilnehmer weiterzuverwenden und für die hohen Datenraten aber SPI auszunutzen um sich das Leben und das Arbeitspensum des uC zu erleichtern. Der uC muss ja schließlich auch noch etwas mit der erbeuteten Datenmenge anfangen. Ist nur meine Ansicht und schönen Tag noch.
:
Bearbeitet durch User
Christian H. schrieb: > An welchem I2C-Kanal ich die Sensoren betreibe, wäre ja grundsätzlich > egal, da der Prozessor während dem Auslesen blockiert wird. Je nun.. Wenn du dir das nicht ohne die blockierende Arduino-lib vorstellen kannst, ist die Aufgabe für dich nicht lösbar. Oliver
Christian H. schrieb: > Ist der Prozessor dann aber nicht zu rund 70% nur mit dem Auslesen der > Daten beschäftigt? Nö, nur wenn man es falsch macht. > 288kBit/s400kBit/s≈0,7\frac{288 kBit/s}{400 kBit/s} \approx 0,7 > (Auch hier wird der Overhead und das Auslesen der anderen beiden > Sensoren noch nicht betrachtet) => Vermutlich liege ich eher bei einer > Auslastung von 90% > > An welchem I2C-Kanal ich die Sensoren betreibe, wäre ja grundsätzlich > egal, da der Prozessor während dem Auslesen blockiert wird. FALSCH! Das wäre nur bei Trivialprogrammierung und Software-I2C so! Bei Nutzung eines Hardware-I2C werden die Bytes von der Hardware übertragen. Die CPU schreibt ein Byte in ein Register, dann kann sie andere Dinge erledigen. Denn 1 Byte dauert bei 400kBit/s und 9 Bit/Bytes ~22,5us. Das ist eine kleine Ewigkeit, erst recht bei 84MHz CPU Takt.
Gerhard O. schrieb: > Der uC muss ja schließlich auch noch etwas mit der erbeuteten > Datenmenge anfangen. Oliver S. schrieb: > Wenn du dir das nicht ohne die blockierende Arduino-lib vorstellen > kannst, ist die Aufgabe für dich nicht lösbar. Genau darum geht es ja. Grundsätzlich wollte ich erstmal nur Gewissheit, dass der Prozessor während des Auslesens blockiert wird. Da mir das nun bestätigt wurde, muss ich mir nun eine neue Lösung einfallen lassen. Entweder arbeite ich per DMA oder ich minimiere die Auslastung durch Nutzung von SPI statt I2C. Wie Gerhard schon erwähnte, sollen die Daten ja auch noch verarbeitet werden.
Christian H. schrieb: > Genau darum geht es ja. Grundsätzlich wollte ich erstmal nur Gewissheit, > dass der Prozessor während des Auslesens blockiert wird. > > Da mir das nun bestätigt wurde, Das mit dem sinnerfassenden Lesen solltest du noch mal üben. Das passiert bestenfalls bei einer blockierenden Software, wie sie Arduino als Standard verwendet.
Falk B. schrieb: > Das mit dem sinnerfassenden Lesen solltest du noch mal üben. > Das passiert bestenfalls bei einer blockierenden Software, wie sie > Arduino als Standard verwendet. Ich habe deine vorherige Nachricht gelesen, allerdings kam sie kurz vor meiner Antwort. Wenn Arduino eine blockieren Software nutzt, wäre es ja nun grundsätzlich besser direkt auf dem NRF52 zu entwickeln. Sollte dort eine Library zu Verfügung stehen, die das HW-I2C auszunutzen weiß, kann ich also 4 IMUs nutzen (jeweils 2 pro Interface). Die Entwicklung auf dem Arduino fällt aufgrund der blockierenden SW ja erstmal raus.
Teensy 4.0 (600 MHz Takt) lässt sich direkt über viele Arduino Libs ansprechen.
Christian H. schrieb: > Die Entwicklung auf dem Arduino fällt aufgrund der blockierenden SW ja > erstmal raus. Ein Arduino Due ist Hardware, die Arduino-Libs sind Software. Merkst du was? Oliver
Selbst bei den alten Atmels kostete die Datenübertragung über die serielle (I²C, SPI, RS232 usw.) Schnittstelle "keine" Zeit. Was anfällt ist die Datenübertragung "in" die zugehörigen Register oder deren Abholung und die Befriedigung Deiner Neugier (jemand zuhause - abholen; Puffer leer - ausgeben). Dabei kann letzteres (die Abfragerei) u.U. die meiste Zeit erfordern. Steht DMA zur Verfügung, musst Du Dich um den zugewiesenen Puffer kümmern. Egal welches System Dir zur Verfügung steht: Unter dem Strich musst Du die Daten - wie auch immer - bearbeiten können, selbst wenn Du sie Byte für Byte ins Null-Device schaufelst. Übrigens: Ein sauber implementierter Ringpuffer ist, verglichen mit der üblichen seriellen Übertragungsrate, immer noch recht flott.
Die CPU hat 84 Mhz, wartet aber die ganze Zeit in I2C Empfangsroutinen? Da muss es doch was besseres geben. Manche CPUs können I2C auch im Interrupt-Betrieb bearbeiten. Und manche haben 4 und mehr parallele I2C Busse, die dann gleichzeitig arbeiten können. Vielleicht sollte man erst das Design der Datenströme machen, und sich danach eine passende CPU aussuchen? Und wenn es wirklich ein Arduino Due sein, muss, weil man nur den kennt, warum nicht 2 oder 3 davon gleichzeitig arbeiten lassen?
PittyJ schrieb: > Und wenn es wirklich ein Arduino Due sein, muss, weil man nur den kennt, > warum nicht 2 oder 3 davon gleichzeitig arbeiten lassen? Der Plan ist bereits mehrere Mikrocontroller zu nutzen, da mindestens 9 Shuttleboards eingesetzt werden sollen (1 Shuttleboard besteht aus IMU (Accelerometer und Gyroskop), Magnetometer und Drucksensor). Ziel ist momentan einfach möglichst wenige Mikrocontroller zu nutzen. Daher die Überlegung zwei Shuttleboards per I2C zu betreiben und zusätzlich eines per SPI => somit wären nur 3 Mikrocontroller nötig. PittyJ schrieb: > Vielleicht sollte man erst das Design der Datenströme machen, > und sich danach eine passende CPU aussuchen? Da ich hier zu Hause zwei Arduino Due rumliegen habe, wollte ich natürlich erstmal daran ein bisschen herumexperimentieren und schauen wie weit ich komme. Gesetzt ist die Nutzung des Due natürlich nicht. Im Laufe der Entwicklung wird vermutlich ein NRF52 zum Einsatz kommen. Falk B. schrieb: > FALSCH! Das wäre nur bei Trivialprogrammierung und Software-I2C so! Bei > Nutzung eines Hardware-I2C werden die Bytes von der Hardware übertragen. > Die CPU schreibt ein Byte in ein Register, dann kann sie andere Dinge > erledigen. Denn 1 Byte dauert bei 400kBit/s und 9 Bit/Bytes ~22,5us. Das > ist eine kleine Ewigkeit, erst recht bei 84MHz CPU Takt. Und um jetzt nochmal Klarheit zu schaffen: Wie ist der Arduino denn aufgebaut? Offensichtlich besitzt er zwei HW-I2C, wird aber durch die SW trotzdem in der Standardlibrary gehalten? Bedeutet für mich, dass ich entweder die Library anpasse (meine begrenzten Coding-Fähigkeiten werden das wohl nicht zulassen) oder ich ändere meinen Plan. Habe mir jetzt auch mal Gedanken gemacht und mir die folgenden vier Optionen einfallen lassen. Nochmal kurz zum Verständnis: Leitungsaufwand und Komplexität soll so gering wie möglich gehalten werden, da Leitungen vernäht werden und sich nicht kreuzen dürfen + hoher Widerstand der Leitungen da keine Standardlitze 1. Mikrocontroller mit DMA Unterstützung -> Auslesen und Beschreiben der Sensorregister finden automatisiert zwischen Speicher und Sensoren statt ohne CPU nennenswert zu belasten 2. Kleinen Microcontroller mit SPI und I2C Interface zwischen Arduino und Shuttleboard schalten -> Mikrocontroller wird ausgelastet -> Arduino zieht Daten per SPI und ist nur zu einem Bruchteil ausgelastet -> Verarbeitung kann auf Arduino stattfinden 3. Kommunikation komplett auf SPI stellen (3-Wire) -> Problem löst sich durch höhere Geschwindigkeit in Luft auf, allerdings höherer Leitungsaufwand (Pro Shuttleboard 5 Leitungen -> 2 Mal Bus (MISO/MOSI & SCK) und 3 Mal Chipselect) 4. Kommunikation ebenfalls komplett über SPI, allerdings ein kleiner Mikrocontroller direkt am Shuttleboard -> Auslesen der Sensoren per SPI und ebenfalls per SPI an Mikrocontroller weiterleiten -> spart 2 Chipselect Feedback hierzu wäre wünschenswert. Vielleicht gibt es ja noch bessere Lösungen. Danke, Christian
wenn du nur begrenzte coding fähigkeiten hast wie willst du das auf den nrf zum laufen bringen? Auch wenn die Dokumentation und das bereitgestellt sehr gut ist. ist das bei weitem kein ardiono mehr. - C - Zephyr os - BLE stack Die Daten vom I2C sind ber IRQ oder per DMA abzuholen. irgend ein einfaches busy wait wird bei deinen anforderungen/fähigkeiten nicht funktionieren. da du 90% deiner CPU zeit in dieser busy Wait loop hängst. Weiter: um Paralellisierung jeglicher art (loopprogramme, Threads, ...) wirst du dich kümmern müssen. ob das ardoino überhaupt bietet ist jetzt die frage die ich nicht beantworten kann. bzw ob die ardonio libs dir die möglichkeiten dazu bieten eine loop programm efektiv zu implementieren.
Christian H. schrieb: > I2C wäre besser geeignet, da der Leitungsaufwand so gering wie möglich > gehalten werden muss und Kreuzung vermieden werden müssen (Leitungen > sollen auf einem Textil vernäht werden) Also der Leitungsaufwand wird dann wohl nicht nur das einzige Problem sein. Bei I²C oder bei SPI, sind die maximalen Längen. Wenn du das auf ein Textil vernähen möchtest, würde ich mal schauen, wie lang du die Leitungen machen kannst.. ohne dass du dir Störungen einfängst. Vor diesem Problem stehe ich auch bald, Test mit SPI bei 0,5 - 1,0m. Unser Hardwareentwickler würde es lieber mit einem RS-485/RS-422 Transceiver aufbauen.
:
Bearbeitet durch User
Christian H. schrieb: > Sollte dort > eine Library zu Verfügung stehen, die das HW-I2C auszunutzen Das geht so nicht. man kann sich nicht drauf verlassen, das einem irgendwer ne LIB schreibt oder zufällig jemand sowas mal geschrieben haben könnte. Am Ende bist Du dann derjenige, der die Shuttle-Bords auf die Textilien näht und jemand anders programmiert das alles. Wenn die Programmiererei nicht deine Kernkompetenz streift, dann hol' Dir jemanden ins Boot, das das (besser?) kann. I2C läuft selbst auf 'nem ollen ATMEGA16 interruptbasierend spielend im Hintergrund. Dafür ist das Ardoino nicht gemacht, der Anspruch war hier ein klein wenig anders. Die Plattform richtet sich an Kunstschaffende, denen man ein kreatives Werkzeug an die hand geben wollte. "Shuttle-Boards auf textilien" klingt ja schon sehr danach, kann ja sein. Aber an bzw. ab einem bestimmten Punkt muss man sein Team eben dann um den Programmierer erweitern oder man legt die Nähnadel/Faden aus der Hand und beschäftigt sich selbst damit intensiver. Weil: ganz so trivial ist es dann nun auch wieder nicht, wie Du ja selbst merkst. Und wie Du richtig angemerkt hattest: Die Daten wollen ja auch noch verarbeitet, visualisiert usw. werden. Neugierde --> Was wird'n das?
Hallo, habe genau so etwas gemacht auf einem STM32G474. Dort alle I2Cs (4 Stück) am Laufen mit 1 kHz. Es funktioniert. Habe die CubeMX Sourcen (interupt nicht DMA) dazu verwendet (quick and dirty). Aber: Bei dem Initieren eines I2C Transfers braucht die entsprechende Routine sehr lange. Die macht busy/wait bis das erste ACK vom Bus kommt, dann schaltet sie erst auf Interruptbetrieb. Insgesamt verbrate ich ein viertel der Prozessorleistung mit diesem Warten. Mit viel Arbeit kann man das bestimmt verbessern. Die Interruptprios waren dadurch sehr hakelig, weil ich mit HW-Timer Interrupt starte. Ansonsten funktioniert es. Mit DMA gab es Probleme beim Hotplug, die nicht zu handlen waren. (Die Sensoren sind hotplugfähig). Auch wenn Du libs hast, heißt das nicht, dass es keine Probleme gibt. Shuttle Board klingt nach Bosch. Darf man erfahren welche Sensoren Du benutzt? Da wäre ich an Erfahrungen interessiert. Martin
Christian H. schrieb: > trotzdem in der Standardlibrary gehalten? Bedeutet für mich, dass ich > entweder die Library anpasse (meine begrenzten Coding-Fähigkeiten werden > das wohl nicht zulassen) oder ich ändere meinen Plan. Da wird wohl Zeit für eine Planänderung. Gärtnern ist auch ein schönes Hobby... Christian H. schrieb: > Der Plan ist bereits mehrere Mikrocontroller zu nutzen, da mindestens 9 > Shuttleboards eingesetzt werden sollen (1 Shuttleboard besteht aus IMU > (Accelerometer und Gyroskop), Magnetometer und Drucksensor). Ganz ernsthaft: such dir jemanden, der das für dich macht, oder lass es. So wird das nichts. Oliver
> Da das System später sowieso nicht auf dem Due, sondern auf einem
NINA-B3 (basiert auf einem NRF52840) laufen soll, werde ich wohl direkt
auf dem Zielcontroller arbeiten, da hier die I2C-Lib wohl DMA
unterstützt
Nun, wenn man nicht weiss wie schenll eine Blackbox library ist hat man
folgende Moeglichkeiten :
- messen
- wegschmeissen
- selbstschreiben
Fuer mich ist das Konzept eine Zusammenstellung akademischer Fuerze.
I2C sei besser wie SPI, wegen der Anzahl Leitungen, welche sich nicht
kreuzen sollen.... Beide Busse wurden nur fuer On-Board gedacht. Die
gehen so nicht in einem Textil. Sie duerfen nicht, wegen EMV, und gehen
auch nicht, auch wegen EMV. Speziell bei hohen Datenraten.
Was bisher noch vergessen ging : billig soll'a auch sein...
Man kann nicht alle Parameter an den Extremen festhalten. 1kHz
Zykluszeit ist eher hoch. Da ist nichts mehr mit billigst Arduino
Hardware, da muss das Sensoren Auslesen in Hardware geschehen. Denn mit
den Sensor Werten soll ja auch noch etwas geschehen. 2 6 Achsen IMU,
bedeuten dann eine Menge an Drehmatritzen in Floating point. Und dann
soll mit diesen gerechneten Resultaten ja auch noch etwas geschehen...
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.