Hallo allerseits, ich habe bis jetzt ausschließlich mit ATmega328P gearbeitet, und dort sowohl I²C als auch SPI im Griff. Nun möchte ich ein kleines batteriebetriebenes Gerätchen bauen, welches einen Sensor per i2c ausliest und die Daten über SPI an ein Funkmodul weitergibt. Das ganze würde mit meinem ATmega sicherlich funktionieren, aber ich überlege ob ich nicht mal was "kleineres" probieren sollte... Eigentlich find ich die 8-poligen ATtiny sehr schnuckelig, bin mir aber nicht sicher ob sich obige Anforderung erfüllen lässt. Dort liegen ja auch I2C und SPI tlw. auf den selben pins, beisst sich das? Es darf aber auch gern ein 14-poliger sein... die haben aber auf den ersten Blick ein etwas anderes TWI, nennt sich dort USI und kann irgendwie auch TWI... kann man da eine bestehende I2C-Implementierung für den ATmega weiterverwenden? Könnt ihr mir da einen Rat geben, worauf ich mich konzentrieren sollte? Ah ja, Versorgung mit 1.8V wäre nett (2 NiMH-Akku-Zellen), Taktfrequenz ist mit maximal 10MHz mehr als ausreichend. und ja, es muss ein AVR sein, ich hab keine Lust die Plattform zu wechseln. Danke!
SPI kannst du je nach geforderter Bitrate leicht per Software realisieren, I²C zur Not auch.
ATXMEGA8E5..32E5, genügend SPIs, UARTs und TWI für viele Anwendungsmöglichkeiten. Als QFN gerade mal 5x5mm oder 4x4mm klein, oder halt 9x9mm im gewohnten TQFP32. 1.8V kein Problem, mit PicoPower geht´s herunter auf wenige µA bei laufendem Uhrenquarz.
http://www.atmel.com/products/microcontrollers/avr/tinyavr.aspx Dort klickst Du auf product search. Die haben da eine sehr umfassende Parametrsuche für ihre Produkte. Wenn Du ATMegas sucht, links oben die Familie wechseln. Und ohne für die Familie eine Vorauswahl zu treffen wird queer durch die Bank gesucht. Dann merkt an, daß die inzwischen in "paar" Chips zur Auswahl haben.
:
Bearbeitet durch User
Michael Reinelt schrieb: > I²C als auch SPI Das können doch meines Wissens alle. Über SPI läuft die normale serielle Programmierung. I2C nennt sich TWI (two wire interface). Der kleinste (Tiny85) als 8-Pinner hat auch TWI mit Einschränkung: 17.3.4 Two-wire Mode The USI Two-wire mode is compliant to the Inter IC (TWI) bus protocol, but without slew rate limiting on outputs and input noise filtering. Pin names used by this mode are SCL and SDA.
Hermann schrieb: > Das können doch meines Wissens alle. Über SPI läuft die normale serielle > Programmierung. Ja nein. Das was Du meinst ist ISP. Darüber können auch Tinys programmiert werden, die weder SPI noch TWI per Hardware haben.
Hermann schrieb: > The USI Two-wire mode is compliant to the Inter IC (TWI) bus protocol, > but without slew rate limiting on outputs and input noise filtering. Pin > names used by this mode are SCL and SDA. Die Tinys haben mit dem USI eine Schrumpfversion von SPI/I2C an Bord, für die "entweder SPI oder I2C" gilt, und die nicht so bequem und leistungsfähig wie die Vollversion ist.
Yalu X. schrieb: > SPI kannst du je nach geforderter Bitrate leicht per Software > realisieren, I²C zur Not auch. Das ist ein interessanter Hinweis, Danke! SPI per software zu machen, klingt logisch! Hermann schrieb: > Das können doch meines Wissens alle. Ja, aber auch "gleichzeitig"? (also nicht gleichzeitig im Sinne von zur selben Zeit TWI und I2c, sondern nacheinander, aber doch beides). ich bezweifle das fast ein bisschen... SPI kann ich "deaktivieren" indem ich einfach kein Slave Select rausgebe. bei I2c dürfte das schwieriger sein... um nochmal auf Yalu zurückzukommen: I2C und SPI bräuchte 5 Signale: SDA/SCL und MOSI/MOSI/SCLK. Ich denke nciht dass sich das kominieren lässt (oder doch?) dann bleiben von 8 Pins nur mehr drei, abzüglich GND/VCC einer, hieße also auf den Quarz verzichten? Geht I2c (Master) mit internem oszillator?
Michael Reinelt schrieb: >> Das können doch meines Wissens alle. > Ja, aber auch "gleichzeitig"? (also nicht gleichzeitig im Sinne von zur > selben Zeit TWI und I2c, sondern nacheinander, aber doch beides). Auch wenn vielleicht intern Verwandtschaft besteht sollte man dennoch ISP und SPI nicht verwechseln. Die Tinys haben zwar ISP, aber kein vollwertiges SPI.
A. K. schrieb: > Die Tinys haben zwar ISP, aber kein > vollwertiges SPI. Oha, danke für den hinweis...
A. K. schrieb: > Auch wenn vielleicht intern Verwandtschaft besteht sollte man dennoch > ISP und SPI nicht verwechseln. Die Tinys haben zwar ISP, aber kein > vollwertiges SPI. Der ATtiny841 hat schon SPI, allerdings beim TWI nur einen Slave.
Yalu X. schrieb: > SPI kannst du je nach geforderter Bitrate leicht per Software > realisieren, I²C zur Not auch. Ich würde es ebenfalls in Software realisieren. Besonders dann, wenn du auf einer der Schnittstellen nur senden und nicht empfangen musst. Und so langsam ist die Software gar nicht. Der ATtiny85 z.B. kann per internem Oszillator mit 16 MHz betrieben werden, das sollte sicherlich ausreichen.
Markus Weber schrieb: > Der ATtiny85 z.B. kann per > internem Oszillator mit 16 MHz betrieben werden Aber nicht bei seinen 1,8V.
A. K. schrieb: > Aber nicht bei seinen 1,8V. Oha, das hatte ich übersehen. Du hast Recht, das wird mehr als eng. 16 MHz sind bei 1,8 Volt wahrscheinlich nicht drin, jedenfalls sicher nicht spezifiziert. Ich weiß nicht, ob ich so ein Gerät mit Akkus betreiben würde oder doch vielleicht besser mit normalen Batterien. Bei so wenig Strom ist die Selbstentladung des Akkus größer als der Stromverbrauch.
16MHz geht sicher nicht, die frage ist ob 8 überhaupt gehen, besser wären vermutlich 4. Allerdings wird die Versorgung ja in der Regel bei 2x1.2=2.4V liegen, und wenn ich die Akkus nicht stark entlade, sollte ich nicht unter 2V fallen. Mal sehen, Versuch macht klug. Sowohl SPI als auch I2C sollten ja zur Not auch mit recht langsamem Takt zurecht kommen, und es ist ja auch nicht viel zu tun: 8 byte per i2c einlesen und per SPI weiterreichen... Weiß jemand von einer empehlenswerten Software-SPI-Implementierung, möglichst Plain-C (also ohne Assembler)?
Michael Reinelt schrieb: > Weiß jemand von einer empehlenswerten Software-SPI-Implementierung, > möglichst Plain-C (also ohne Assembler)? Wenn es nur ums Senden geht,dann kannst du etwas so simples wie das Beitrag "Re: [Sammelbestellung] [DycoLED] RGB LED mit integr. seriellen Controller" verwenden, Funktion dyco_byte()
soft i2c Beitrag "I2C (TWI) Sniffer mit AVR" /EDIT Ups sorry nicht software. Aber evtl trotzdem hilfreich ;)
:
Bearbeitet durch User
Jörg Esser schrieb: > soft i2c > Beitrag "I2C (TWI) Sniffer mit AVR" > /EDIT > Ups sorry nicht software. Aber evtl trotzdem hilfreich ;) Danke! ich les immer gerne Code vom Peter ;-)
Michael Reinelt schrieb: > um nochmal auf Yalu zurückzukommen: I2C und SPI bräuchte 5 Signale: > SDA/SCL und MOSI/MOSI/SCLK. Ich denke nciht dass sich das kominieren > lässt (oder doch?) Es wird wohl keinen Chip geben, der das Hardwaremässig so angelegt hat, aber wenn Du wenigstens eine der Schnittstellen mit Software machst, kannst Du ruhig SDA mit MISO oder MOSI zusammenlegen, der aktive Takt bestimmt, welcher BUS läuft. Dann bist Du bei vier Pins. Michael Reinelt schrieb: > welches > einen Sensor per i2c ausliest und die Daten über SPI an ein Funkmodul > weitergibt. Wenn Du einen SPI Sensor nimmst, brauchst Du noch einen Chip Select, also auch vier Pins. Es ist aber dann einfacher zu programmieren. Zu den SPI / ISP Gerüchten (interne Verwandschaft und so was) bitte mal hier lesen: [http://www.mikrocontroller.net/articles/Serial_Peripheral_Interface] ISP ist also eim Protokoll für den SPI Bus, der selber keins mitbringt, sondern eigentlich nur eine Hardware Definition der Schnittstelle ist.
Maik Jahabeich schrieb: > kannst Du ruhig SDA mit MISO oder MOSI zusammenlegen, der aktive Takt > bestimmt, welcher BUS läuft Bist du sicher? Soweit ich weiss wird eine Änderung von SDA (und das müsste ich wohl, wenn das auch für MISO oder MOSI verwendet wird) bei SCL=high als Start oder STOP interpretiert. Kann zwar sein dass das nicht weiter stört, aber schön isses nicht...
Christopher B. schrieb: > Vielleicht hilft dir ja das weiter > http://www.i2cchip.com/mix_spi_i2c.html Okay... danke! klingt zwar nach etwas längeren Debug-Sitzungen, sollte aber machbar sein.
Michael Reinelt schrieb: > Weiß jemand von einer empehlenswerten Software-SPI-Implementierung, > möglichst Plain-C (also ohne Assembler)? Master oder Slave, das ist hier der Knackpunkt. Beim Betrieb als Master spielt ein exaktes Timing, hoher Durchsatz und insbesondere geringe Latenz keine große Rolle. Das ist auch in C sehr gut beherrschbar, man muß einfach nur halbwegs richtig programmieren können, dann ist das in einer Viertelstunde oder so funktionsfähig implementiert. Im Slave-Betrieb sieht das allerdings völlig anders aus. Da kann es schon aus dem Grund keine empfehlenswerte Plain-C-Implementierung geben, weil mit C kein vorhersagbares Zeitverhalten erlaubt und damit auch keine vertrauenswürdige Spezifikation der möglichen Datenrate. Das wird erst möglich, wenn der relative Fehler nur noch Bruchteile der Datenrate beträgt und damit unwichtig wird, also konkret: bei (extrem) geringer Datenrate. Und wenn diese Randbedingung gegeben ist, dann braucht man auch bloß wieder richtig programmieren zu können und hat Kram in einer Viertelstunde geschrieben. Also wenn es ein schneller Slave sein soll und rein in Software implementiert, kommst du um Assembler nicht herum. Irgendein Herumgekruckse in C könnte zwar fast die gleiche Geschwindkeit erreichen, aber der einzige Vorteil von C, die angebliche "Portabilität" ist dann einfach wech'. Der Code ist dann genauso portabel wie Assembler, also von Natur aus nur auf dem gleichen Core mit identischen Laufzeitverhalten ausführbar, mit ein bissel Tricksen mit bedingter Compilierung auf allen Cores der gleichen Familie. C bietet dann keinerlei Vorteil mehr. Warum sollte man sich also den ganzen Syntax-Bläh dann noch freiwillig antun?
Das stand schon ganz am Anfang: der μC ist TWI und SPI Master. Also muß man gar nicht erklären, warum es als Slave mit C nie gehen würde. Wobei auch nirgends steht, daß ein eventueller Master diesen armen Sklaven im μs Bereich mit Daten zuballern würde. Aber wichtig: es kann auf keinen Fall mit C gehen. Schon aus Prinzip! nur mal 2 Link aus Google: http://extremeelectronics.co.in/avrtutorials/code/SoftI2Clib_for_AVR.zip Beitrag "SPI per Software"
Bastler schrieb: > Das stand schon ganz am Anfang: der μC ist TWI und SPI Master. Stimmt, das hatte ich wohl überlesen. Dann verstehe ich allerdings das Problem des OP nicht. Tiny841 und gut isses. SPI per SPI-fähiger UART, besser geht nicht und I2C per Software. OK, I2C ist wesentlich komplexer als SPI und damit ist es auch ein viel umfangreicheres Werk, es in Software zu implementieren, aber dafür gibt es ja fertigen Code. > Also muß man gar nicht erklären, warum es als Slave mit C nie gehen > würde. Sagt wer? Du scheinst da ein noch viel gravierenderes Leseproblem zu haben als ich.... Ich habe sehr differenziert beschrieben, was geht und was nicht geht. Und jeder, der wirklich was vom Programmieren im Allgemeinen und C im Speziellen versteht, wird mir ganz sicher insofern Recht geben, als daß meine Darstellung den Sachverhalt exakt trifft... Der einzige Fauxpas war halt, daß es im konkreten Fall am Thema vorbei ging, weil ja SPI-Slave überhaupt nicht gefordert war. Das ändert aber nichts an der Korrektheit der Darstellung für den Fall, daß ein SPI-Slave tatsächlich zu implementieren wäre...
SPI beschreibt das Protokol aber keine Zeiten, um auch mal spitzfindig zu sein. Und bei einem SPI-Takt von 1kHz kann das sogar BASIC.
c-hater schrieb: > Tiny841 und gut isses natürlich könnt ich einen 16-poligen verwenden (wobei dann eher der 84, da als DIP verfügbar), meine Frage war aber, ob man das auch mit einem 8-Füßler zusammenbringt,
Michael Reinelt schrieb: > Bist du sicher? Soweit ich weiss wird eine Änderung von SDA (und das > müsste ich wohl, wenn das auch für MISO oder MOSI verwendet wird) bei > SCL=high als Start oder STOP interpretiert. Kann zwar sein dass das > nicht weiter stört, aber schön isses nicht... Ich würde SCL auf low iehen, ist zwar unüblich, aber funktioniert. Dann gibts kein Start.
Michael Reinelt schrieb: > c-hater schrieb: >> Tiny841 und gut isses > > natürlich könnt ich einen 16-poligen verwenden Tiny841 hat nur 14 Beinchen. > (wobei dann eher der 84, > da als DIP verfügbar) Der hat eben nicht den Luxus zweier UARTs, die obendrein beide als perfekte SPI-Master benutzbar sind. Das ist der entscheidende Unterschied. Aber ja, ich würde es auch bevorzugen, daß es den 441/841 auch in DIP gäbe. Das hätte es mir erst letzte Woche erspart, so ein Teil manuell auf einen SOIC-DIP-Adapter zu brutzeln. Zehn wertvolle Minuten, die ich lieber dem eigentlichen Problem gewidmet hätte, was mit der aufgebauten Versuchsschaltung zu evaluieren war, von dem absolut unverschämten Preis, den z.B. RS für so einen primitiven Adapter aufruft, mal gleich ganz zu schweigen. Aber das war ja immerhin wenigstens nicht mein Geld. ;o) > meine Frage war aber, ob man das auch mit einem > 8-Füßler zusammenbringt, Wenn man programmieren kann, geht es natürlich auch mit einem Tiny 85/45/25. Aber es wird nie so gut werden, wie mit einem Teil, was die Hälfte der Arbeit paktisch komplett in Hardware erledigen kann. Richtig performant geht das dann nur in Hardcore-Assembler, also mit quasi-"paralleler" Ausführung. Also mit sozusagen "verschränktem" Code. Damit bist du aber dann aber wenigstens bei einem Tiny45. Bei einem Tiny25 reicht der Flash sicher nicht für alle nötigen Varianten der Verschränkung, dazu ist I2C leider zu komplex.
Michael Reinelt schrieb: > I2C und SPI bräuchte 5 Signale: > SDA/SCL und MOSI/MOSI/SCLK. Ich denke nciht dass sich das kominieren > lässt (oder doch?) dann bleiben von 8 Pins nur mehr drei, abzüglich > GND/VCC einer, hieße also auf den Quarz verzichten? Geht I2c (Master) > mit internem oszillator? Wird alles vom LPC810 in DIP8 erfüllt. Aber geht ja nicht: Michael Reinelt schrieb: > es muss ein AVR sein
1 μC, der als Master 2 Busse steuert, die beide alle Macht dem Master geben. Wo muß da etwas parallel "verschränkt" laufen? Oder sollen die Messdaten mit Mega-Samples erfaßt werden? Das "Funkmodule" dürfte da niedrige Grenzen setzen. Suche mit "avr bitbang spi" bzw. "avr bitbang i2c master" liefern diverses. Die I2C Version existiert sogar Als Atmel AppNote. In C mit ClockStrech damit der Slave etwas trödeln kann und mit ca 750 Byte Flash.
c-hater schrieb: > Richtig > performant geht das dann nur in Hardcore-Assembler, also mit > quasi-"paralleler" Ausführung. Also mit sozusagen "verschränktem" Code. Was ist denn "verschränkter" Code? Das hört sich für mich nach Blödsinn aus der Esoterik-Welt an. Dort werden auch regelmäßig Begriffe aus der Quantenphysik missbraucht, um schlau zu klingen und Geld zu machen. Und wie schon gesagt: Es gibt unter anderem auch App Notes direkt von Atmel, die sich der Thematik widmen. Und bei I2C ist das Clockstretching Teil der Spezifikation, sodass man auch dann keine Daten verliert, wenn man zu langsam ist. Mit freundlichen Grüßen, Karol Babioch
Maik Jahabeich schrieb: > aber wenn Du wenigstens eine der Schnittstellen mit Software machst, > kannst Du ruhig SDA mit MISO oder MOSI zusammenlegen, der aktive Takt Mit MISO wird das ein bisschen schwierig, aber mit MOSI geht es. Um allen Problemen aus dem Weg zu gehen, sollten die Clockleitungen getrennt sein, also 2 Pins. Weitere 2 für SDA/MOSI und MISO. SS, wenn vorhanden, dauernd auf Log.0, beide Clockleitungen auf Log.0. Wenn Clockleitung auf Null gehalten wird, kann das auch nicht zu einer Fehlinterpretation führen (START/STOP). Wie man es auch dreht und wendet, mindestens 4 Pins für I2C und SPI. Bleiben ohne RESET 2 Pins, mit RESET nur einer.
Karol Babioch schrieb: > Was ist denn "verschränkter" Code? Das ist Code, der sich zwei Sachen quasi gleichzeitig widmen kann, indem er die Wartezeiten, die bei der Behandlung der einen Sache auftreten, für die Behandlung der zweiten sinnvoll benutzt (idealerweise dasselbe auch noch umgekehrt). Also ungefähr das, was C-ler auch mal bei ereignisorentierter Programmierung auf einer viel gröberer Zeitskala hinbekommen. Bloß im eben im Bereich einiger weniger Takte. Der Unterschied ist, daß dein Durchsatz für ein Byte sich ungefähr so errechnet: Zeit für Einlesen per I2C PLUS Zeit für Ausgabe per SPI. Bei verschränktem Code bestimmt hingegen der langsamere Kanal (fast) alleine den Durchsatz. Weißt du jetzt ungefähr, was ich meinte? Wenn nicht, machen wir doch einfach mal einen kleinen Wettbewerb. Du in C, ich in Asm. System: Tiny@8MHz mit Soft-I2C (400kHz) als Quelle und Soft-ISP (VMax) als Ziel, beides als Master. Ziel der Programmierung soll sein, maximalen Datendurchsatz von der Quelle zum Ziel zu erreichen. Dir wäre natürlich die Verwendung von Assembler (über das hinaus, was ohnehin schon in den diversen libs steckt) verboten. Wetten, daß ich ganz erheblich mehr Durchsatz schaffen werde als du? Und das wird nur zu einem kleinen Teil auf die Ineffizenz deines Compilers als solchem zurückzuführen sein, der weitaus größere Teil des von mir erzielten Performancevorteils würde ich genau durch den Trick des "verschränkten" Codes erzielen.
Irgendwie kommt mir das vor, wie wenn ich an einer roten Ampel stehe, so zum Spaß mal mit dem Gas spiele und der Knabe neben mir bei Grün die Reifen stinken läst. Wieso sollte man HighPerformanceUnlesbarCode schreiben, wenn man ein par Bytes von einem Sensor zu einem popeligen FunkModul schieben will? Oder steht irgendwo konkret, daß es hier um Ersatz eines 300MB WLan geht? Wir wissen natürlich alle, daß du das kannst. In Assembler! Nur wer braucht's?
c-hater schrieb: > Bei einem > Tiny25 reicht der Flash sicher nicht für alle nötigen Varianten der > Verschränkung, dazu ist I2C leider zu komplex. Ach Gottchen ne, Du must C wirklich sehr wenig kennen. Für die reinen I2C-, SPI-Master reicht 1kB dicke. Und die Übersetzung von dem einen Protkoll in das andere sollte auch bequem in 1kB passen.
c-hater schrieb: > Karol Babioch schrieb: > >> Was ist denn "verschränkter" Code? > > Das ist Code, der sich zwei Sachen quasi gleichzeitig widmen kann, indem > er die Wartezeiten, die bei der Behandlung der einen Sache auftreten, > für die Behandlung der zweiten sinnvoll benutzt (idealerweise dasselbe > auch noch umgekehrt). Mir ging es eher um die Wortwahl. In diesem Zusammenhang ist mir "verschränkter" Code noch nie untergekommen. Das ist eine Kreation deinerseits und eigentlich Blödsinn. Ich würde das eher mit kooperativem Multitasking beschreiben. Das ist ein Begriff, welcher sich auch in Lehrbüchern wiederfindet und ungefähr dem entspricht was du meinst. c-hater schrieb: > Wetten, daß ich ganz erheblich mehr Durchsatz schaffen werde als du? Gegenwette: Wetten, dass mein Code lesbarer und portabler ist ;). Aber was genau prangerst du jetzt überhaupt an? Meinen Programmierstil, oder die Verwendung von C? Soll das jetzt wirklich zu einem C vs. Assembler-Thread ausarten? Mit freundlichen Grüßen, Karol Babioch
Man kann etwas beim Namen nennen oder beschreibend. In diesem Falle ist durch ein adjektiv alleine beschreibend schon genauer gesagt was der ungefähr passende Name aussagt. Kooperatives Multitasking ist ein weitreichender Begriff. Nicht alles was darunter fällt würde hier passen. Verschränkung verdeutlicht die innige Verzahnung der Arbeitsabläufe. Ich fand es sowohl präziser als auch veständlich und kompakt formuliert. Das ist auch kein Assembler vs c Thema. Auch keine Kritik an c. Es ging um Software vs Hardware und das man, zumindest in diesem Falle, mit Software etwas tricksen muß um mit einer Hardwarelösung mithalten zu können, wenn überhaupt. Es hat ja keiner gesagt daß das schön, lesbar und wartbar sein wird, wobei das nicht ausgeschlossen ist. Das ist auch nicht das Thema, Aber ein solches verzahntes Tuning lohnt sich meist nur bei Notwendigkeit (wenn an die maimale perforance braucht) oder bei relativ kleinen essentiellen Basisroutinen die häufig genutzt werden, wie in diesem Beispiel. Die Softconvertierung eines Datentroms stützt ich auf die Softconvertierung eines Bytes mit vielen durchläufen. Auch wenn das nicht sonderlich gut lesbar oder wartbar ist, so ist das nicht so schlimm. Da muß man nicht wieder ran. Das ist Code der schon fast wie eine Hardwarefunktion genutzt wird. Wie solche Basisbausteine intern aufgebaut sind muß man bei Gebrauch weder bei Software oder Hardware wissen. Hauptsache der Gebrauch ist verständlich und übersichtlich.
:
Bearbeitet durch User
Multitasking geht hier nicht, da ja die gleichen Pins für beides benutzt werden. Multipinning schließt Multitasking aus. Man muß erst den I2C Sensor einlesen und kann danach über SPI ausgeben. Damit es nicht zu Fehlinterpretationen kommt, muß das SPI genau so langsam sein, wie das I2C (100kHz) und darf SDA nur ändern, 5µs nachdem SCL = 0 ist.
Peter Dannegger schrieb: > Multitasking geht hier nicht, da ja die gleichen Pins für beides benutzt > werden. Wieso denn das? Wenn beides rein in Software implementiert ist, hat man bei der Wahl der Pins doch völlig freie Hand. Und die Zahl der Pins würde bei den Achtbeinern locker ausreichen, da könnte sogar Reset noch Reset bleiben. Allerdings: Es ergibt tatsächlich keinen Sinn, SPI mit höherer Bitrate zu betreiben als I2C. Allerdings aus einem ganz anderen als dem von dir genannten Grund, nämlich: Es muß nur die Daten wegschreiben können, die reinkommen und das werden dank des etwas größeren Protokolloverheads von I2C bei gleicher Bitrate immer weniger sein, als in der gleichen Zeit rausgehen könnten.
Hier geht es um eine Art Buskoppler für einen Sensor. Der Bus wird mit an Sicherheit grenzender Wahrscheinlichkeit den größten Teil der Zeit im Leerlauf sein. Daher denke ich, daß wir uns hier derartige Gedanken nicht machen brauchen.
c-hater schrieb: > Und die Zahl der Pins > würde bei den Achtbeinern locker ausreichen, da könnte sogar Reset noch > Reset bleiben. I2C: 2 SPI: 4 = 6 Da muß er schon den Reset disablen oder Pins mehrfach nutzen.
So, jetzt war ich eigentlich soweit, mich an einem tiny841 zu versuchen. Den krieg ich mit meinen Anfänger-SMD-Künsten auch gelötet. Etwas abschreckend wäre halt, das ich das Teil nicht sockeln kann, und damit im Fall des Verfusens oder so das Ding nicht einfach tauschen kann. Aber gut, versuchen wirs halt. Dachte ich. Jetzt lese ich, der tiny841 hat zwar I²C, aber nur Slave :-( Ja kann denn das wahr sein?
Konrad S. schrieb: > Der ATtiny841 hat schon SPI, allerdings beim TWI nur einen Slave. Bei den Tinys ist I²C-Master selten. Da fällt mir nur noch der ATtiny48/88 ein.
:
Bearbeitet durch User
Michael Reinelt schrieb: > Jetzt lese ich, der tiny841 hat zwar I²C, aber nur Slave :-( Dann machste eben das I2C zu Fuß. Langsamer wirst Du dadurch nicht, das HW-SPI kann ja parallel arbeiten.
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.