Schönen Tag! Ich suche nach einer Möglichkeit einen der kleinen attinys. Zb. Attiny13 mit einem AtMega zu verbinden. Die sollen miteinander kommunizieren, da der Attiny13 aber kein Hardware UART hat, fällt das schonmal aus. Soweit ich weiß hat der Attiny13 garkeine Hardwareseitige möglichkeit zu kommunizieren, ist das richtig? Muss ich also jegliche Kommunikation in Software ausprogrammieren? Ich denke UART wäre dabei ungeeignet aufgrund des hohen Programmieraufwands ( großer Speicherbedarf ) und erhöhte Störanfälligkeit. Schonmal ein danke an die Profis Grüße Oliver
1) Atmel hat zu einer Software Uart auf einem avr ein pdf. Soweit ich mich erinnere; war ein kurzer code und benötigt nur 2 I/Os. 2) Software I2C oder SPI Slave empfinde ich ich als aufwändiger (min. 3 I/O). 3) Wenn du kannst, nimm ATTinys mit Hardware spi, i2c usw.
Hallo! 1) Danke, werds mir mal anschauen 2) mehr als 2 I/Os kann ich sowieso ned opfern leider. 3) Attiny13 liegen schon hier, deshalb eher nicht möglich. Auch an One-Wire habe ich gedacht problem ist aber, dass ich es Potentialfrei übertragen möchte, mit Optokopplern und das macht gewisse Probleme, da selbige eben nicht bidirektional arbeiten können. Gruß Oliver
Hallo avion! Den Kenne ich, aber damit habe ich ja auch das Problem des one - wires oder? Weil ich eben eine galvanische Trennung per Optokoppler brauche. Grüße Oliver
Oliver. A. schrieb: > Den Kenne ich, aber damit habe ich ja auch das Problem des one - wires > oder? Weil ich eben eine galvanische Trennung per Optokoppler brauche. Warum denn das? Wenn beide mit den selben Pegeln arbeiten einfach verbinden.
Hallo! Ich muss mehrere kleine Attinys zu dem Atmega verbinden, die Attinys sind aber auf unterschiedlichem Niveau, also nicht alle auf der selben Masse. Aus diesem Grund ist die galvanische Trennung essentiell. Grüße Oliver
Oliver. A. schrieb: > Den Kenne ich, aber damit habe ich ja auch das Problem des one - wires > oder? Weil ich eben eine galvanische Trennung per Optokoppler brauche. Der Empfang erfolgt über Pin-Change-Interrupt, also kannst Du nen beliebigen anderen Pin nehmen. Es muß nicht der Sendepin sein, kann aber. Peter
Hallo Peter! Heißt also, ich kann es genauso auftrennen wie bei UART, Beidseitig einen Sende, und einen Empfangspin richtig? Hat der 124BUS Vorteile gegenüber UART bzw. Nachteile? Wäre es eventuell Schaltungstechnisch auch möglich über einen I/O Port des µC das 124 BUS System galvanisch getrennt zu übertragen.? einfach 2 Optokoppler geht natürlich nicht, das ist mir klar. Grüße Oliver
Oliver. A. schrieb: > 124BUS Vorteile gegenüber UART Einer ist, dass die Taktfrequenz von Sender und Empfänger nicht allzu genau sein muss.
Hallo! Stimmt, zumal ich keine Quarze verwenden möchte. Hat er auch Nachteile? Grüße Oliver
Hier noch etwas zu one-wire: http://www.atrox.at/1wire/opto/ Komlette Trennung, eine Pin - aber ob ein Quarz nötig ist hängt von der Datenrate ab....
Hallo! Danke für den Link, sieht auch nicht schlecht aus, interessant wäre es hald wies mit der Einfachkeit bzw. Störsicherheit und Nachteile aussieht. Was meint ihr da ? 124Bus oder UART, oder was würd da besser sein? Grüße Oliver
Oliver. A. schrieb: > Stimmt, zumal ich keine Quarze verwenden möchte. Das ist eine schlechte Idee ... Oliver. A. schrieb: > Hat er auch Nachteile? - langsam - störanfällig - übersteht keinen EMV Test
Hallo! Störanfälliger als der UART? Wieso soll der weniger EMV beständig sein wie der UART? Langsamer ist eine Auslegungssache oder? Denn Störungsfreier ist doch der 124Bus ( Mit Störungsfrei meine ich jetzt wegen des Timings ) und somit kann ich höhere Datenraten verwenden. Oder bin ich komplett am falschen weg ? Grüße Oliver
Lehrmann Michael schrieb: > - langsam > - störanfällig > - übersteht keinen EMV Test Schönes Beispiel für pauschale Aussagen, vollkomen wertlos. Peter
Hallo Peter. Eine Begründung dazu wäre schon immer schon :D Kannst du mir diese Fragen (Vor/Nachteil) eventuell beantworten ( mit Begründung) wär super! Danke dir. Grüße Oliver
Oliver. A. schrieb: > Hallo Peter. > > Eine Begründung dazu wäre schon immer schon :D Ja, die fehlt eben. Da mußt Du schon den Lehrmann Michael fragen, wie er darauf kommt. EMV ist hauptsächlich eine Hardwaresache (Schaltplan, Layout). Mit SW kann man bestenfalls Störungen abfangen (CRC, Retry, Timeout). Peter
Hallo! Dachte ich mir auch. Aber Peter was ist deines erachtens besser, und eventuell auch leichter zu realisieren? Grüße Oliver
Wenn die kleinen Controller mit RC-Oszillator laufen kann es sinnvoll sein, die Daten über eine Art "Morsecode" zu übertragen. Sprich man überträgt kurze und lange Pulse. Mit einer Schleife, oder einem Timer kann man die Länge sehr einfach bestimmen, und dann mit Grenzen vergleichen. Ganz kurze Pulse ignoriert man, längere sind beispielsweise 0-en, ganz lange sind zum Beispiel 1-en, und wenn sie noch länger sind, so sind das Startbits. (oder ähnlich) RC-Oszillatoren können durchaus mal 10% "Fehler" haben, eine normale serielle Schnittstelle kommt da an ihre Grenzen. Das oben beschriebene Verfahren funktioniert auch noch bei deutlich größeren Fehlern. Da man auch die Länge der Pulse bestimmt kann man sogar den Frequenzfehler bestimmen.
Christian Berger schrieb: > "Morsecode" Genau das ist PeDas 124-Code. Wo ist eigentlich der Ursprungsbeitrag dazu?
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.