Hi zusammen, ich hoffe das es das richtige Forum ist, wenn nich bitte verschieben. Ich habe ein Projekt bei dem ich 20 ATTinys2313A via I2C mit einem ATMega8A steuern muss. Die Tinys sind auf einer Strecke von 20-40m verteilt und brauchen jeweils 5V und maximal 60mA an Strom. Ja ich weiß I2C ist eigentlich für geräteinterne Kommunikation vorgesehen. Jedoch muss es möglichst günstig sein und da bietet sich I2C einfach an. Auf die Länge möchte ich mit einer niedrigen Geschwindigkeit und ggf. über einen Extender kommen. Jetzt zu meiner Frage. Die Tinys sollen, wenn möglich, über ein Kabel mit Strom und I2C versorgt werden. Daher dachte ich an 2 DIN-Stecker an jedem Tiny, die sowohl I2C als auch den Strom abgreifen und durchschleifen. Als Leitung hätte ich eine Fernmeldeleitung wie z.b. YSTY 2X2-10 genommen, da diese ja auch geschirmt ist. Da ich jedoch scheinbar bei den Vorlesungen über Schirmung und Signalübertragung gepennt habe, würde ich mich freuen wenn sich das jemand kurz anschauen und seinen Senf dazu geben würde. Grüße Benedikt
:
Verschoben durch User
Okay, ich habe nicht direkt eine Frage gestellt, aber es wird doch sicherlich jemand schon ähnliches gemacht haben oder zumindest Erfahrung mit DIN-Steckverbindungen haben. Aber hier eine konkrete Frage: Ist diese Steckerverbindung und die Leitungsauswahl in Ordnung oder könnte/wird es da Probleme geben? Ich würde mich über eine Antwort freuen. Benedikt
Du willst einen I2C Bus missbrauchen um damit 40 m zu überbrücken und willst jetzt vom Forum die Absolution dafür? Die Idee ist quatsch. Nimm RS232 oder noch besser RS485. gruß cyblord
Hi Benedikt, ich hatte schon mal so ein ähnliches Problem und dazu den NXP P82B715 [1} verwendet. Ich habe damals eine ungeschirmte 4-adrige Telefonleitung hergenommen. Hat über 20m problemlos geklappt (länger brauchte ich es nicht). Als Steckverbinder hatte ich RJ12 in Verwendung. Liebe Grüße, Lui [1] www.nxp.com/documents/data_sheet/P82B715.pdf
Benedikt schrieb: > Ich habe ein Projekt bei dem ich 20 ATTinys2313A via I2C mit einem > ATMega8A steuern muss. Die Tinys sind auf einer Strecke von 20-40m > verteilt und brauchen jeweils 5V und maximal 60mA an Strom. > > Ja ich weiß I2C ist eigentlich für geräteinterne Kommunikation > vorgesehen. Jedoch muss es möglichst günstig sein und da bietet sich I2C > einfach an. Das ist Pfusch, dafür ist I2C nicht gedacht und nicht geeignet. Ja, es gibt immer wieder Bastler, die sowas aufbauen, und oft funktioniert es zufällig auch, aber ich rate ganz klar davon ab. Für sowas nimmst Du RS485 oder CAN. Oh, schade, es gibt ja keine kleinen AVRs mit CAN. Tja. Der intelligente Entwickler schaut sich dann bei anderen Herstellern um und greift dann z.B. zu einem PIC18F25K80 - der ist leistungsmäßig in einer ähnlichen Klasse, hat aber mehr Peripherie (2 UART, SPI, I2C, CAN) und liegt bei etwa 2€. Den Mega8A kannst Du auch damit ersetzen, oder den nächstgrößeren PIC18F26K80 mit mehr Speicher nehmen. > Daher dachte ich an 2 DIN-Stecker an jedem Tiny, die sowohl I2C als auch > den Strom abgreifen und durchschleifen. Ungünstig. DIN-Stecker haben keine Verriegelung. Entweder Sub-D (das kannst Du festschrauben) oder die in der Industrie gerne verwendeten M8 oder M12 Rundstecker (die aber nicht wirklich billig sind) oder irgendwas anderes, was per Rastung oder Schraubung gegen unbeabsichtigtes Herausfallen gesichert ist. Wenn es eine ortsfeste Installation ist, sind auch Schraub- oder Federklemmen ok, wenn Du für eine Zugentlastung sorgst. > Als Leitung hätte ich eine Fernmeldeleitung wie z.b. YSTY 2X2-10 > genommen, da diese ja auch geschirmt ist. Das sind starre Kabel, die für eine ortsfeste Verlegung gedacht sind. Ist das bei Dir der Fall? Und zu Deinen 5V? Glaubst Du ehrlich, dass wenn Du an einem Ende 5V reinschickst, das am anderen Ende auch noch ankommt? Alle Clients zusammen brauchen immerhin 1.2A. Normal macht man das so, dass man den Bus mit einer möglichst hohen Spannung (üblich sind 48V, z.B. bei Power Over Ethernet oder ISDN S0) speist und dann vor Ort in jedem Client die passenden Spannungen per Schaltregler erzeugt. Vorteil: hohe Spannung -> geringe Ströme -> wenig Spannungsabfall. Zum Bus: CAN und RS485 müssen an jedem Ende mit einem 120 Ohm Widerstand abgeschlossen werden, damit es keine Signalreflektionen gibt. Außerdem brauchst Du noch einen Transceiver für jeden Busteilnehmer. Für CAN nimmst Du MCP2551 oder PCA82C251 oder sowas in der Richtung. > Da ich jedoch scheinbar bei den Vorlesungen über Schirmung und > Signalübertragung gepennt habe, würde ich mich freuen wenn sich das > jemand kurz anschauen und seinen Senf dazu geben würde. Ich denke, Du hast noch bei ganz anderen Sachen gepennt. fchk
Such mal nach "1draht" von P.Dannegger in der Codebase. Billig, einfach und ohne "dafür aber nicht gemacht" Problem.
Danke für die Antworten, ich habe inzwischen schon neue Anforderunen bekommen und bis auf das "I2C-Problem" hat sich alles erledigt. Vorerst werden RJ12 Buchsen und Stecker verwendet und die Stromversorgung erfolgt ggf. an mehreren Stellen. Ob ich bei I2C bleibe oder auf etwas anderes umsteige wird sich noch zeigen, jedoch wollte ich es nicht unversucht lassen.
Ich würde auch RS485 nehmen. Spätestens beim nächsten Gewitter weißt du, dass man einen "nackten" AVR-Pin nicht an eine lange Leitung hängen soll. Gruß Roland
Beim nächsten Gewitter bin ich vorraussichtlich schon wieder weg und der nächste Student hat das Problem :-D Spaß bei Seite, ob es überhaupt so eingesetzt wird steht noch nicht fest, denn das Projekt ist eher zum erweitern meiner Kenntisse und Fähigkeiten. Und bis zum Projektende habe ich, falls nötig, noch genug Zeit um auf ein anderes Bussystem umzustellen. Danke für die Vorschläge und Antworten, vorerst ist mir geholfen.
Also wenn das länger halten soll, nimm einen Raspberry Pi und nimm Shellskripte. Die sind selber erklärend.
Was ich damit meine ist, dass man alles auf einer SD-Karte hat, inklusive dem Quellcode, sprich es kann nichts verloren gehen.
Benedikt schrieb: > Als Leitung hätte ich eine Fernmeldeleitung wie z.b. YSTY 2X2-10 > genommen, da diese ja auch geschirmt ist. > Da ich jedoch scheinbar bei den Vorlesungen über Schirmung und > Signalübertragung gepennt habe, würde ich mich freuen wenn sich das > jemand kurz anschauen und seinen Senf dazu geben würde. Ich hab I2C über 100m Cat5 mal mit- und mal ohne aufgelegte Schirmung getestet -> kein Unterschied in Funktion und am Oszi feststellbar. Hat beides wunderbar funktioniert (Mit P82B96 als Treiber). Ich weise wie üblich hin auf: http://www.mikrocontroller.net/articles/I2C_als_Hausbus
Ich weiß das ein embedded linux hier wahrscheinlich die schnellere und einfachere Lösung wäre, und privat hätte ich mir auch ein Gnublin oder einen Raspberry geholt und es damit gelöst. Jedoch ist hier (Semesterprojekt) der Weg das Ziel und ich soll ja auch was neues dazu lernen. Sowohl Software, als auch Hardware ist schon gebaut bzw. fast fertig. Es ging mir prinzipiell nur um Leitungs- und Steckerauswahl, daher habe ich es auch ins Hardware-Forum gepackt.
Der Knackpunkt bei I2C ist, dass da einfache rechteckige Signale übertragen werden. Kabel in dieser Länge können solche Signale aber nicht verzerrungsfrei übertragen. Ohne zum Kabel passenden Abschlusswiderstand werden Schwingungen und Echos entstehen, die deine Clock-Impulse vervielfachen. Das kannst Du mit einem Oszilloskop ganz einfach antesten. Bau Dir mal einen Signalgeber, der ähnlich dem I2C Signal Clock Pulse erzeugt. Schließe daran das lange Kabel an und messe dann mal in der Mitte des Kabel mit einem Oszilloskop, was da an kommt. Richtige Abschlusswiderstände lassen sich bei RS485 relativ leicht einsetzen. Bei I2C ist das nicht so einfach, weil I2C keinen differential-Eingang hat. Man kann sicher RS485 Transmitter/Receiver missbrauchen, um damit I2C Protokoll zu fahren. Ich würde das allerdings nur machen, wenn das I2C Protokoll fest vorgegeben ist.
Benedikt schrieb: > Sowohl Software, als auch Hardware ist schon gebaut bzw. fast fertig. Es > ging mir prinzipiell nur um Leitungs- und Steckerauswahl, daher habe ich > es auch ins Hardware-Forum gepackt. Oh mann... Erst bauen und dann Fragen, wie wärs mal andersrum?
Naja, die 2 Probleme mit I2C sind, dass man a) keine symmetrische Signalführung hat und somit Brummschleifen usw entstehen können und, dass man b) keine definierte Impedanz hat, und man somit immer Reflexionen bekommt, schlimmer noch die Impedanz ist für beide Symbole unterschiedlich. Somit kann man da höchstens probieren das ganz langsam zu machen und die Pullups möglichst klein zu machen, so dass keine gefährlichen Spannungen entstehen können. Als Hausbus ist das beim besten Willen nicht geeignet. CAN ist schon ein wenig besser, hat aber das Problem, dass die Symbole nicht symmetrisch um die 0V liegen, somit ist Dämpfung ein ernsthaftes Problem. Das Protokoll hat weiter noch Probleme mit Leitungen die länger als eine Bitlänge sind. So als Hausbus würde ich was RS485 oder besser Ethernet-basiertes nehmen. Da hat man symmetrische Leitungen mit definierter Impedanz. Besonders Ethernet ist absolut potentialfrei. Nebenbei kann man beides trivial mit Computern verbinden ohne dass man irgendwelche Spezialsoftware braucht. UDP und serielle Schnittstelle geht überall trivial. (so lange man nicht gerade unter Windows ist)
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.