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
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
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.
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)
