|
Anzeige
|
MCU mit 24-Bit-SPI?Hi, ich nutze aktuell den ATSAMD51G für ein Projekt, bei dem ich 3 Byte/24 Bit Daten über ein SPI interface empfange. Der ATSAMD51G bietet die Möglichkeit, die Anzahl der in einem SPI-Frame zu empfangenden Bytes zu konfigurieren, weswegen ich den dafür ausgewählt habe. Mein Problem: die Lieferzeiten von dem Ding sind mittlerweile astronomisch. Deswegen meine Frage: kennt jemand eine andere MCU, welche mindestens zwei SPIs mit mehr als 16 bit Datenbreite bietet? Danke!
Wozu? Die allermeisten uCs haben ein SPI mit 8 Bit/Elementartransfer. Damit kann man problemlos ganzzahlige Vielfache von 8 Bit übertragen und das alles in Hardware (=schnell).
Und was genau nützt mir 3x 8 Bit (mit 3x Wackeln auf der Select-Leitung) wenn ich 1x 24 Bit mit 1x Wackeln auf der Select-Leitung benötige?
Wer sagt denn, daß CS da dreimal wackelt? Das wird in den allermeisten Fällen per CPU geschaltet und ist damit frei programmierbar.
Der Empfänger erwartet drei mal Wackeln wenn er nur 8 Bit SPI-Frames kann! Und wenn das nicht passt, werden entweder die zusätzlichen Bits oder das ganze SPI-Frame verworfen, weil das Eingangs-Schieberegister eben schlichtweg keine 24 Bit breit ist!
Wovon redest du denn eigentlich? Du fragtest nach einem Controller, der 24 Bit per SPI empfangen kann. Das kann jeder! Denn nach jedem Byte ist erstmal Ruhe. Ich gehe davon aus, daß dein Controller der SPI-Master ist, welcher auch den Takt generiert. Dann kann der Controller das empfangene Byte speichern. Dann sind die nächsten zwei Bytes drann. Wo liegt da das Problem? SPI funktioniert so und das schon seit Anfang an und auch auf den allermeisten Controlleren, die nur 8 Bit / Einzeltranfer in Hardware beherrschen.
Wovon redest du eigentlich? Von Master war nirgends die Rede! Aber ich erkläre es dir gerne: CS geht auf LOW -> Framebeginn Clock wackelt und signalisiert jeweils ein gültiges Datenbit -> dieses wird in das Eingangs-Schieberegister geschoben CS geht auf HIGH -> Frameende, die MCU schiebt die Daten aus dem Eingangs-Schieberegister in irgend ein Empfangsregister oder FIFO oder was auch immer. Was du mir gerade versuchst zu erzählen: Wenn das Eingangs-Schieberegister nur 8 Bit hat, kann ich da trotzdem 24 Bit drin empfangen, weil die überschüssigen 16 Bit ... ja bitte wo landen die denn? Und wieos soll nach 8 Bit Ruhe sein, wenn der Sender eben 24 Bit in einem Frame schickt und nicht 8? Erklärst du mir gerade, wie die Daten aussehen, die ich empfangen möchte? Aber wenn ich das hier lese:
...dann hast du offenbar noch immer nicht verstanden, dass ich vom EMPFANG rede und nicht vom SENDEN! Der Empfänger programmiert nicht das CS-Signal! Mouser hat angeblich 270 Stück PIC32MK0512GPK im TQFP-64.
Angehängte Dateien:
In der Tat. Deine bisherige Beschreibung war unvollständig.
Dein Controller ist also der Slave, richtig?
ja, aber da bleibt immer noch die Frage.
Versuchs mal mit Bladrian oder wenn das nicht hilft mit Val_ium. Du bist vollkommen überdreht! Geh mal davon aus, daß ich weiß wie SPI funktioniert, sowohll was den Master als auch Slave angeht. Mangels genauerer Informationen DEINERSEITS habe ich angenommen, daß der gesuchte Controller als Master arbeiten soll. Auch der kann Daten vom Slave lesen/empfangen. Und das mit BELIBIGER Byteanzahl. Für deine 24 Bit braucht es da KEINERLEI Spezialcontroller. Wenn aber dein Controller als Slave arbeiten soll, muss er sich dem Timing des Taktes sowie CS anpassen. Auch ein SPI-Slave kann mehr als nur 8 Bit empfangen, auch wenn die Hardware nur ein 8 Bit Schieberegister enthält. der Slve-Controller muss nur schnell genug am Ende der ersten 8 Bit diese abholen und im RAM speichern. Kann er das nicht, werden die empfangenen Daten überschrieben und des entsteht Datensalat. Ist das SPI in Empfangsrichtung doppel gepuffer, wie z.B. ein UART, ist das relativ entspannt, der Controller hat ca. 8 Bitzeiten Zeit, die Daten abzuholen und zu speichern. Gibt es die Doppelpufferung NICHT, wie z.B. im AVR, muss der Master eine Zwangspause von ein paar us einlegen, um dem AVR-Slave genügen Zeit zum Speichern des BYtes zu geben. Allerdings kann beim AVR der UART im SPI-Mode arbeiten, damit bekommt man ein SPI mit Doppelpufferung. Somit könnte ggf. soger ein einfacher AVR als SPI-Slve deine mageischen 24 Bit empfangen.
Das habe ich versucht zu erklären. Wenn dein Controller der Master ist und den Takt vorgibt.
Vielleichst solltest du dich mal mit dem Thema Netiquette befassen. Deine Informationen waren unvollständig und ich kann nicht hellsehen.
Und du scheinst nicht verstanden zu haben, daß auch ein SPI-Master Daten empfängt.
In der Tat! Ich versucht mal zu dekodieren. Du suchst einen uC, der als SPI-Slave 24 Bit empfangen kann. Richtig? Bei welchem SPI-Takt? Wieviel Zeit liegt zwischen den Bytes?
Du hast gerade das Gegenteil bewiesen... Du hast scheinbar SPI nicht verstanden. CS dient -wie du richtig erkannt hast- als Framestart-Condition. Nach jeweils 8 bit wird -per Hardware- der Inhalt des Schieberegister in das Empfangregister kopiert, und ein Interrupt ausgelöst, der dir signalisiert, das die ersten/nächsten 8bit abgeholt werden müssen. Das passiert bei 24bit eben 3 mal, und am Ende hast du alle 24 bit.
Aha. Was bedeutet wohl MISO beim SPI? Falks Beschreibung ist richtig, vielleicht solltest du mal Grundlagen zu SPI lesen. Viele Cortex-M haben 16 Bit Register, da ginge auch 16+8 oder 12+12 Bit.
Und das ist beim ATSAMD51G eben NICHT so! Ich bekomme den Interrupt, so bald im Schieberegister die Anzahl von Bits liegen, die ich zuvor konfiguriert habe - und das sind 24. Und noch mal: was macht dein 8-Bit-SPI denn, wenn CS einfach nicht hochgeht? Stupide die Bits zählen? Das Frameende nur vermuten?
JA! Was sonst? Es ist eine SYNCHRONE Schnittstelle!
Nö, das muss er schon wissen. Die Software muss es auch wissen. Außerdem kann man das CS auch per Software auswerten. SPI in Contollern ist nie zu 100% Hardware.
Tja....du solltest dich wirklich nochmal in SPI einlesen! CS bleibt während der gesamten 24bit auf aktiven Pegel. Das Schieberegister schiebt einfach stumpf mit jedem Takt weiter, und es werden alle 8 Takte Interrupts ausgelöst. CS geht erst am Ende des Transfer wieder auf inaktiven Zustand.
Natürlich die Bits zählen und alle 8 Bits (oder was sonst als Wortbreite für den SPI-Controller konfiguriert ist) einen neuen Interrupt generieren bzw. per DMA das Byte/Teilwort wegspeichern. Kein vernünftiger SPI-Controller braucht die steigende Flanke von CS- als Frameende-Markierung. Das inaktiv werden von CS- nach dem letzten Zugriff deselektiert lediglich den Slave, so daß der aufhört, MISO zu treiben. Was glaubst du wohl, wie sich ein SPI-Slave in einem serial FLASH Speicher verhält?!? Der wird auch nicht erst aktiv, wenn CS- wieder inaktiv wird, sondern liefert nach dem Empfang des Lese-CMD, mehreren Adreßbytes und einem Dymmy-Byte Byte für Byte die gespeicherten Daten auf MISO zurück! Und wenn man möchte den ganzen Speicherinhalt am Stück, incl. Wraparound am Speicherende auf den Anfang. So, nach dem Sich Falk hier scheinbar mit seinem Zweit- und Drittaccount selber Recht gibt, habe ich es am ATSAMD51 einfach mal ausprobiert: SPI-Empfang auf 8 Bit gestellt und Eingangsseitig 24 Bit pro CS-Frame gesendet. Ergebnis: ich erhalte NICHT 3x 8 Bit und 3 Interrupts! Die Empfangs-Bitbreite muss also zu der in den CS-Frames gefundenen Anzahl Bits passen. Ansonsten wäre das ja auch eine saublöde SPI-Schnittstelle, wenn das CS-Signal so nutzlos ist: Steckt jemand während einer laufenden Übertragung das Kabel an, wird einfach irgendwo im Byte angefangen, die Bits einzusammeln. D.h. die empfangenen Daten wären permanent verschoben. Resynchronisation? Nö, CS ist ja nutz- und sinnlos und es werden nur stupide Bity geschoben. Aber ist schon gut @bauformb hat es ja zum Glück geschafft, mir meine eigentliche Frage zu beantworten - Danke dafür!
;-)
Dann hast du entweder was falsch eingestellt oder der Controller kann es nicht. Ich weiß es nicht, ich kenn das Ding nicht!
Bei dem Ding vielleicht. Der Rest der Controller hat das Problem nicht.
Das hat keiner behauptet. Aber CS ist im Wesentlichen nur für ein definiertes Reset der SPI-Logik zuständig. Klar, wenn CS wieder auf HIGH (inaktiv) geht, kann man da noch andere Aktionen starten.
Frag. Was machst du, wenn dein SPI-Master 16 Byte Daten sendet? Brauchst du dann einen Controller, der das rein in Hardware empfangen kann?
Gast
#7403912
Das ist erreicht wenn 8bit empfangen wurden. Clocks zählen ist ja nicht so kompliziert. CS bleibt so lange aktiv wie dieser Slave gemeint ist. CS ist nur insofern das Frame start signal weil es den Slave komplett deaktivieren kann WENN es überaupt vorhanden ist. Der Slave kann auch mit permanentem CS am SPI hängen, wenn es keinen zweiten Slave gibt. Auch wenn Falk sich gerne erst im Ton vergreift, um dann die patzigen Gegenreaktion seinen Gegenübers von ganz weit oben herab zu bemängeln, hat er in der Sache Recht. Das einzige was Deine tolle MCU ausmacht ist das sie einen mehrfach gepufferten SPI Eingang hat und Dich eben erst informiert wenn 3 Byte empfangen wurden. Das macht ja oft Sinn, wenn die CPU nicht jedes Byte abholen muss, sondern erst gestört wird wenn alles vorliegt. Das hat aber nichts damit zu tun das nicht jede beliebige billo MCU 24bit über SPI empfangen kann, WENN Du rechtzeitig die Daten abholst bevor die nächsten 8bit empfangen wurden.
Quatsch! Ein weiterer Beweis, daß du SPI absolut nicht verstanden hast. So ganz verstehe ich die Diskussion nicht - wenn ich z.B. eine SDCard im SPI-Modus anspreche, dann stehen zwischen den CS-Wechseln u.U. Hunderte von Megabytes.
Da brauchst du gar nicht so rumzuschreien. SPI ist immer ein AUSTAUSCH von Daten. Zwischen Senden und Empfangen gibt es, bis auf Unterschiede bei der Auswertung, keinen Unterschied. Das läuft parallel über MOSI und MISO ab, wobei der Takt durch den Master vorgegeben wird. Aus dem Datenblatt "35.6.2.6.2 Client In Client mode (CTRLA.MODE=0x2), the SPI interface will remain inactive with the MISO line tri-stated as long as the SS pin is pulled high. Software may update the contents of DATA at any time as long as the Data Register Empty flag in the Interrupt Status and Clear register (INTFLAG.DRE) is set. When SS is pulled low and SCK is running, the client will sample and shift out data according to the Transaction mode set. When the content of TxDATA has been loaded into the Shift register, INTFLAG.DRE will be set, and new data can be written to DATA. Similar to the host, the client will receive one character for each character transmitted. A character will be transferred into the two-level receive buffer within the same clock cycle its last data bit is received. The received character can be retrieved from DATA when the Receive Complete interrupt flag (INTFLAG.RXC) is set. When the host pulls the SS line high, the transaction is done and the Transmit Complete Interrupt flag in the Interrupt Flag Status and Clear register (INTFLAG.TXC) will be set. " Vermutlich hat der OP die Interrupts verwechselt und anstatt des INTFLAG.RXC den INTFLAG.TXC benutzt. Den gibt es natürlich nur einmal, wenn SS auf HIGH geht. Mit einem FPGA wäre das nicht passiert ... mit einem uC sind immer unschöne Pausen auf der Taktleitung zwischen jeweils 8 Takten.
Keineswegs.
Nein! ... wenn man es richtig macht. Hier Anschauungs-Material (zwei 8-Bit Transfers auf einen STM32F407): Habt Gnade, ich wollte doch nur etwas trollen (-:
Das kann man hinterher leicht sagen. Wir sehen deine lange Nase ja nicht.
Dürfte man denn wissen von welchem SPI-Partner da die Rede ist? "35.8.10 Length Name: LENGTH Bit 8 – LENEN Data Length Enable In 32-bit Extension mode, this bit field enables the length counter. Value Description 0 Length counter disabled 1 Length counter enabled Bits 7:0 – LEN[7:0] Data Length In 32-bit Extension mode, this bit field configures the data length after which the flags INTFLAG.RCX or INTFLAG.DRE are raised. Value Description 0x00 Reserved if LENEN=0x1 0x01-0xFF" Here we go. Muss man halt alles richtig einstellen.
Wenn der Slave halbwegs schlau ist, dann nutzt er die Deselektion auch dazu, seinen Kommunikations-Automaten zurücksetzen. Dann geht es beim nächsten Selektieren sicher wieder von vorne los, auch wenn sich der Automat z.B. wegen einer Störung mal "verstolpert" hat.
Und mit einem FPGA könnte man auch SPI mit 17 oder 23 Bits machen. ;-)
Der ist bestimmt wieder strenggeheim. Sonst fiele ja die gesamte Argumentation des TO in sich zusammen.
Toll, damit dann 99% aller Mikrocontrollern den Scheiß mit Soft-SPI ansteuern dürfen, so wie es einige ASICs machen . . . Nicht alles was technisch machbar ist, ist auch sinnvoll. Eine ganzzahliges Vielfaches von 8 als Bitanzahl sollte im 21. Jahrhundert machbar ein . . .
Noch ist nicht geklärt ob der Controller des TO als Master oder Slave konfiguriert ist. Oder hab ich etwas überlesen? Den Peripherie-Baustein möchte ich erst noch sehen der einen Mikrocontroller im Slave-Mode braucht um seine Daten zu senden.
Das hast du. Es ist ein Slave.
Nun ja, das Wort Slave hat er nie geschrieben, sich aber über meine Annahme Master aufgeregt. Daraus schließe ich, es ist ein Slave. Kann mich aber irren! ;-)
Ähm, was? Der Mikrocontroller ist doch sicher der Master und gibt den Takt vor, oder? Nach 8 Clocks einfach mal den Clock anhalten und das SPI-Register abfragen. Und dann die nächsten 8 Clocks schicken usw.. 24 bit Frames (oder auch mehr) ist bei SPI ja jetzt nichts ungewöhnliches. Ich hatte letztens erst ein Gerät, dass hatte sogar ein 24 Byte-SPI-Frame. Das war für den Atmega mit einem 1 Byte großen SPI-Empfangsregister auch kein Problem mit nur einmal CS wackeln lassen.
Oder. Es ist ein Slave. Das hatten wir schon.
Klar, kann man so machen. Oder auch gleich die fallende Flanke auf CS- dafür nutzen, um den Automaten hart einzusynchronisieren. Kommt im Zweifelsfall darauf an, wie das worst-case-Timing des Masters ist, also wieviel Zeit einem von der fallenden CS-Flanke bis zur ersten Aktivität auf der Taktleitung bleibt.
Mir ist mal beruflich ein System untergekommen, das verwendete auf den verschiedenen Steckkarten spezielle UARTs in FPGAs, die asynchron 500000-18-N-1 miteinander kommunizierten. Also ein (fast) normaler UART, aber mit 18-Bit Wortbreite mit einem Startbit und einem Stopbit ohne Parität. Glücklicherweise kann der Serial-Decoder in der Saleae-Software so konfiguriert werden um das korrekt zu decodieren, wenn ich es mit dem Logic 16 aufgezeichnet hab. Bei solchen Sonderprotokollen lernt man neue Flüche...
Wenn der TO sich so still heimlich leise zurückzieht dass man keine weitere Klärung erfährt dann weiss man normalerweise was davon zu halten ist.
Megacool, war wohl eine PDP-15? Früher konnte man einfach so praxisgerechte Wortbreiten bauen, nicht sowas ;)
Jain. Es gibt ADCs mit SPI die 12 oder 14 oder mit Vorzeichen sogar 13 oder 15 Bits liefern. Wenn man da die maximale Abtastrate schaffen will, dann verschenkt man besser keine überflüssigen Takte am SPI. Selten so selbstgefälligen Mist gelesen. Liest sich fast so wie der Thread Beitrag "SPI-Slave ATSAMD51 / 24 Bit Frames empfangen" Die Funkstille des TO rührt sicher daher, das Selbiger den Hinweis zum Datenblatt (RTFM) befolgte…
Da Lesen offenbar nicht so deine Stärke ist: ich habe mich zurückgezogen, weil ich eigentlich bereits eine Antwort auf meine Frage erhalten habe. Was soll ich hier noch weiterdiskutieren und 30 sinnlose Postings abseits der eigentlichen Fragestellung lesen, wenn das Ego von "Falk" und Co noch nicht mal damit klarkommt, was ich explizit an der Hardware verifiziert habe? Deswegen: Bye und ein schönes Leben noch!
Du bist nur bockig und ignorant. Wollen wir wetten, daß du die Interrupts falsch konfiguriert hast? So wie du auch diverse Grundlagen von SPI nicht verstanden hast? Ich glaube, kauf mir einfach so ein Board, programmier es und werde beweisen, daß dem so ist. Die paar Euro ist mir das wert ;-) LOL! Der TO bildet sich immer noch ein, seine SPI Kommunikation funktioniere nur mit diesem einen Controller im ATSAM-irgendwas und nicht mit jedem x-beliebigen 8-Bit SPI-Controller...
So weit, so gut. Der Slave kann als seine SPI-Hardware aktivieren und der Software sagen, das jetzt eine Frame startet. Die Software hat darüber hinaus per Definition die Vorab-Information, dass der Frame aus drei Payload-Bytes besteht.
Ja, und nach 8Bits weiss der Slave, dass eben dieses voll ist, weil die Hardware halt weiss, dass da nur 8 Bit reinpassen. Die Situation kann dann auf drei verscheidene Weisen behandelt werden. Entweder per Polling oder per Interrupt oder per DMA. Bei korrekter Programmierung führen alle drei Verfahrensweisen letztlich dazu, dass ein Byte aus dem Empfangsregister im Speicher landet und ein Bytezähler inkrementiert wird.
Hier wird's dann komplizierter. Normalerweise interessiert dieses Event nicht, denn da hat man schon vorher die Information bekommen, dass drei Bytes in den Speicher übertragen wurden. Tracken sollte man es trotzdem, um eine vollständige Behandlung aller denkbaren Fehler zu gewährleisten.
Du Klops hast noch nie was von DMA gehört. Das ist wohl im Kern dein Problem. Aber auch ohne DMA kann man die Sache handlen (wenn die MCU schnell genug ist), entweder per SPI-Byte-Interrupt oder sogar per Polling, denn in beiden Fällen führt man ja einen Bytecounter mit, der halt bei drei sein sollte, noch bevor CS wieder auf High geht. Man muss halt einfach nur denken und programmieren können, das ist schon alles. Schwierig wird es bei SPI eigentlich nur dann, wenn die zu empfangene Bitzahl kein Vielfaches von 8 ist.
Das Leben wäre so einfach wenn du uns deinen (geheimen) SPI- Partner nennen würdest. Dann würde es dir (und ggf. uns) wie Schuppen aus den Haaren fallen wie klar das alles ist. Da das aber nicht passiert muss man dir Unbelehrbarkeit und Starrsinn attestieren. Dir würde vermutlich ein Zacken aus der Krone fallen wenn du uns dein SPI Peripheral nennen würdest. Zu erwähnen ist noch, dass das SPI Empfangs-Registern bei vielen Controllern gepuffert ist, also wenn ein Byte empfangen wurde kann schon das nächste durch das Schieberegister getaktet werden, man muss rechtzeitig die Daten lesen. Die ATSAM SERCOM sind gepuffert und der SPI von einem ATMEGA328 zum Beispiel auch. Ja, in dem Ausschnitt den Falk aus dem Datenblatt gepostet hat steht schon "two-level receive buffer", ich wollte es nur mal explizit erwähnen. Und was die ATSAM angeht, wenn der ATSAMD51G nur für den SPI im Projekt ist könnte der vielleicht durch einen ATSAMD21G ersetzt werden. Die ATSAMD21 haben sehr ähnliche SERCOM Einheiten, allerdings ohne den 32 Bit Mode. Die ATSAMD21 sind fast Pin-Kompatibel, Pin 41 und 43 sind anders belegt. Und es sind "nur" Cortex-M0+ mit 48MHz. Aber die wären sehr ähnlich programmierbar und Mouser und Digikey haben davon im Moment tausende auf Lager. Master, Slave .... das ist doch auch nicht mehr zeitgemäß
Jaja, der liebe Zeitgeist . . . https://de.wikipedia.org/wiki/Zeitgeist Besser Cheffe und Ali? ;-)
Die Diskussion gibts tatsächlich.
Weiß ich! Auch Arduino ist woke! https://content.arduino.cc/assets/A000066-full-pinout.pdf "CIPO/COPI have previously been referred to as MISO/MOSI" MASTER, MASTER, MASTER! https://www.youtube.com/watch?v=IsvfofcIE1Q ;-)
Das Thema ist schon längst geklärt. https://hackaday.com/2020/06/29/updating-the-language-of-spi-pin-labels-to-remove-casual-references-to-slavery/
Es gibt durchaus SPI Devices, die nehmen jeweils die zuletzt vor der steigenden Flanke eingetakteten Bits für sich. Solche Devices kann man dann in einer Kette (Daisy-Chain) hintereinander anschließen, ein paar hundert Bits durchtakten und zum Schluss mit der steigenden SS# Flanke allen zusammen sagen, dass die Daten jetzt gelten.
Die RSPIc der Renesas RX Familie können das
Z.B. R5F565N7ADFP https://mou.sr/3Hxw1el Grüße
Wie kommst Du auf das schmale Brett, daß /SS 3* wackeln muß? /SS hat genau 2 Aufgaben:
Typisch ändert sich /SS also genau am Anfang und am Ende eines Pakets. Wieviel Bytes ein Paket lang ist, interessiert nicht. Einen Interrupt erhältst Du jeweils zur eingestellten Bitzahl je Wort (8, 16, 24 usw.)
Wie kommst Du darauf nochmal das Thema von vorne aufzurollen wo wir doch schon mit Penetranz erlebt haben dass der TO beratungsresistent und stur ist, und sich in die Aufklärung des Problems nicht (mehr) einbringen will? Der Grund der Verabschiedung hat sich ja zwischen den Zeilen auch bereits gezeigt:
Also ich weiss jetzt nicht wieso ihr so auf dem TO herum hackt, weil in seinem ersten Post steht explizit das:
Er sucht eine Alternative zum ATSAM -> dann muss dieser wohl auch als Empfänger herhalten... Also ob jetzt der Controller als Slave konfiguriert wird, steht zwar nicht wortwörtlich da, aber von diesem Text auf ein Master zu schliessen ist doch schon sehr weit her geholt. Und zur Thematik CS = Copy-Event: Das finde ich nicht so abwegig, weil sonst würden alle Daisy-Chains nicht funktionieren (was soweit ich weiss ja auch Jahrzehnte Standard ist). Aber ich glaube die Ursprungsfrage wurde beantwortet und die restlichen 80% an Posts, naja...
Von einem extern per SPI angeschlossenem ADC muss man auch schon mal 24 Bit empfangen, das macht den ADC aber nicht zum Master.
Danke Lothar, hab mich schon gewundert warum das nicht erwähnt wurde. Wir haben für ein Projekt 20MCUs in Daisy Chain verschaltet. Da war das SPI Feature mit steigender Flanke essentiell. Ist meiner Meinung nach wichtiger als die fallende...
Ein MCP3424 sendet sein ADC Wert, der vom µC empfangen wird, u.a. auch in einem 3 Byte/24 Bit Frame. Er ist deshalb aber dennoch kein Master. Und es gibt viele SPI-Slaves, die ihre Daten in x Byte/ 8*x Bit Frames senden. Das ist nun wahrlich keine Seltenheit. ;)
Also ich dachte der kann nur I2C. Naja…
Da hab ich mich vertan, ich dachte der hat SPI, wie der MCP3903, bei dem man den CS-Pin auch nur zum Start und zum Ende der Übertragung umschaltet und es einem quasi völlig egal sein kann, ob man 1 Byte oder 10 Byte durch den durch schiebt ;) Antwort schreibenBitte melde dich an, um einen Beitrag zu schreiben. |
Anzeige
|
