mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Mehrere AVRs miteinander verbinden - Spezielle Bedinung


Autor: Chris L. (hazdur)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Leute,

ich habe vor, in den kommenden Wochen ein neues Projekt zu starten. 
Dieses beinhaltet mehrere AVR uC miteinander zu verbinden. 
Dementsprechend habe ich mich ueber die gaengigen Moeglichkeiten zur 
Kommunikation zwischen mehreren uC etwas schlau gemacht, habe aber 
leider nicht das gefunden, was ich genau suche. Darum hier dieser 
Beitrag:

Bei dem Projekt soll es einen Master-uC geben, an dem ein Display und 
Keypad angeschlossen sind. Abhaengig von Eingaben, die man dort machen 
kann, sollten mehrere Slave-uC angesprochen werden. Diese Slave-uC 
steuern dann weitere Peripherie an. Die Verbindung zwischen den uCs ist 
auf dem angehaengten Bild dargestellt.

Zuerst ein paar Gegebenheiten:
 - Nur der Master sendet Daten an die Slaves. Nicht umgekehrt.
 - Ein "Datenpaket" enthaelt 32 Bit (8 Bit Adresse, 24 Bit Nutzdaten).
 - Jeder Slave bekommt seine Adresse ueber einen Dip-Schalter 
zugewiesen.
 - Die Entfernung zwischen Master und Slaves kann einige Meter betragen.
 - Taktraten aller uC mindestens 8MHz

Nun die erste Frage dazu: Ist eine Kommunikation ueber mehrere Meter 
ueberhaupt moeglich (>5m)?
Nach meinem Wissensstand scheiden somit die Verfahren SPI und I2C schon 
einmal aus, da diese eher fuer kurze Entfernungen ausgelegt sind?


Nun die Bedingung:
Es kann vorkommen, dass alle Slaves die selben Nutzdaten bekommen 
sollen. Ist dies der Fall, sollen diese auch moeglichst gleichzeitig 
darauf reagieren. Somit muss es moeglich sein eine Nachricht 
gleichzeitig an alle Slave-uCs zu senden.
Aus der Sicht eines Slaves sollen Datenpakete akzeptiert werden, bei 
denen die eigene Adresse mit der im Datenpaket uebereinstimmt oder die 
Adresse im Datenpaket gleich Null (0x00) ist (Definition eines 
Datenpakets an alle Slaves).

Noch einmal mit anderen Worten: Der Master kann ein Datenpaket an einen 
einzelnen Slave oder alle Slaves senden. Sendet er an alle, sollen alle 
Slaves moeglichst gleichzeitig darauf reagieren.

Waere dies mit TWI oder UART grundlegend realisierbar?


Eine Idee von mir, dies zu realisieren:
Ich hatte mir gedacht, vor jedem Slave ein separates 8 Bit 
Schieberegister 
(http://www.mikrocontroller.net/articles/AVR-Tutori...) 
zu platzieren. Sollen nun Daten an einen Slave-uC gesendet werden, 
schiebt der Master zunaechset 8 Bit eines Datenpakets gleichzeitig in 
jedes Schieberegister jedes Slaves (Eins pro Slave). Sind die ersten 8 
Bit in jedem Schieberegister, setzt der Master das RCK Signal 
(Low-High-Low). Bei der steigenden Flanke werden die Daten somit von 
jedem Schieberegister auf die parallelen Ausgaenge gelegt. In jedem 
Slave wird bei der fallenden Flanke ein Interrupt ausgeloest, dass die 8 
Bit einliesst und erstmal im Speicher ablegt. Dieser Vorgang wird mit 
den restlichen 24 Bit eines Datenpakets wiederholt. Wurde ein Datenpaket 
komplett uebermittelt, entscheidet jeder Slave, ob die Daten fuer ihn 
gueltig sind oder nicht. Fertig!

Ist dies ueberhaupt verstaendlich geschrieben? Falls ja, realisierbar??


Ich bedanke mich zuerst einmal fuers lesen und erneut fuer eine Antwort. 
:)

Schoenen Gruss

Autor: Weinbauer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Schau Dir mal CAN-Bus oder RS485 an.
I2C geht auch auf x Meter.
Schieberegister? Für was? Die AVR haben TWI und UART mit
dabei, brauchste nicht.

Autor: Max (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Diese geschilderte Lösung scheint etwas kompliziert.
Wenn so etwas machen müsste, dann würde ich AVRs mit CAN-Hardware 
verwenden und via CAN kommunizieren. Vorteil: problemlos bei diesen 
Entfernungen, und es werden weniger Leitungen benötigt (CAN_L, CAN_H, 
GND)
Ausserdem könnte man problemlos eine bidirektionale Kommunikation 
realisieren, und es gibt auch CAN Libraries wodurch nicht das Rad 
komplett neu erfunden werden muss.

viele Grüße

Max

Autor: Floh (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nimm i2c, wenn du nicht zu schnelle Datenraten hast.
Die eingebaute Twi-Hardware übernimmt dir das ganze Managment, du musst 
nur noch die Datenbytes verwenden und die Adressen einstellen.
:-)

Autor: Knut Ballhause (Firma: TravelRec.) (travelrec) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Am unkompliziertesten ist UART. Wenn man genug davon hat, sollte man das 
nehmen. Bei kurzen Wegen <1m kann man z.B. alle RX-Leitungen verbinden 
und jede TX-Leitungen mit einer Diode (mit Kathode an den TX-Pin) an 
diese gemeinsame Leitung anschließen. Die gesamte Leitung wird mit einem 
Pullup nach VCC gezogen. Dann kann man im Halbduplex auf dieser Leitung 
sowohl im Single-, als auch Multimasterbetrieb arbeiten. Der 
Multiprozessor-Kommunikationsmodus ist dabei hilfreich und arbeitet mit 
bis zu 256 Adressen.

Autor: Tsmc (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also ich würde das ganz über RS485 lösen. Wie Herr Ballhause schon sagt 
hat man den Vorteil das die AVRs einen MPCM (Multi-processor 
Communication Mode) haben. Hier für werden Daten und Addresse mit Hilfe 
des 9 Bit unterschieden. Die Addressen sind frei konfigurierbar und man 
kann natürlich auch welche doppelt belegen z.B.: (0x00) für Braodcast. 
Mit RS485 sind auch 5 Meter kein problem und man hat nur zwei Drähte und 
kann ein Bus-System aufbauen.

Autor: Knut Ballhause (Firma: TravelRec.) (travelrec) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Tsmc schrieb:
> Mit RS485 sind auch 5 Meter kein problem

Mit RS485 sind nicht mal 500m ein Problem ;-)

Autor: H.Joachim Seifert (crazyhorse)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mit nur einem master ist RS485 ideal.
Einfach, billig, störfest.

Autor: avion23 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Von Peter Dannegger gibt's in der Code-Sammlung einen 124-Bus. Dieser 
hat den Vorteil gegenüber rs232, dass die Taktabweichung bis zu 25% 
betragen kann. Bei rs232 sind es bis zu 4%. Selber ausprobiert habe ich 
ihn noch nicht.

Autor: Ulli (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
RS485 ist wohl nicht der Weissheit letzter Schluss, da:
Keine Sterntopographie
Keine Stichleitungen

Habe demnächst das selbe Problem, aber noch keine echte Lösung.
Würde gerne RS232 verwenden.
Habe aber das Problem, dass die Slaves "wahllos" dazu gesteckt werden 
müsen.
Es sind also mal mehr und mal weniger Slaves vorhanden. Damit muss der 
Bus auch Stichleitungen vertragen können.

Meine Slaves werden maximal 5m vom Master entfernt sein.

Wenn jetzt hier keiner laut schreit, dann werde ich es einfach 
probieren.

MfG
Ulli

Autor: Knut Ballhause (Firma: TravelRec.) (travelrec) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ulli schrieb:
> Würde gerne RS232 verwenden.

RS232 ist kein BUS, sondern eine Punkt-zu-Punkt-Verbindung. Die oben 
vorgeschlagene Lösung mit den Dioden könnte für Dich funktionieren. Wenn 
man den/die Pullups schaltbar macht, kann man jedes Ende eines Strangs 
terminieren. Um das Ganze noch vor elektrostatischer Entladung zu 
schützen, kann man serielle Widerstände vor jedem Controller vorsehen.

Autor: spess53 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

>RS485 ist wohl nicht der Weissheit letzter Schluss, da:
>Keine Sterntopographie
>Keine Stichleitungen

Dann lies mal hier:

www.national.com/an/AN/AN-1057.pdf

MfG Spess

Autor: Chris L. (hazdur)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Vielen Dank an alle erst einmal fuer die Antworten!

Ich habe mir jetzt darauf hin TWI und RS485 nochmal etwas genauer 
angeschaut und weiter gelesen. Dazu nun noch kurz ein paar 
Verstaendnisfragen:


TWI:
Ich kann ja jedem Slave ein eigene Adresse zuweisen (TWA Register bei 
den AVRs). Wenn ich jedem Slave die gleiche TWI-Adresse zuweisen wuerde 
und der Master an diese Adresse sendet, dann sollten ja ansich alle 
Slave die Daten bekommen (Broadcast). Falls soweit richtig:
 - Wuerde das dann nicht Probleme mit dem internen TWI-Management geben?
 - Jeder Slave sollte doch entsprechend ein ACK zuruecksenden, wenn 
dieser zum Empfang von Daten bereit ist.
 - Der Master wuerde es vermutlich nicht mitbekommen, wenn ein Slave 
kein ACK gesendet hat -> ein Slave bekommt die Nachricht nicht?


RS485:
Um diese Art der Uebertragung zu realisieren, braucht man ja noch 
zusaetzlich die entsprechenden Treiber ICs. Freund Google konnte mir 
nach eine kurzen Suche die beiden folgenden IC aufzeigt: SN75176A und 
MAX485. So wie ich das auf den ersten Blick sehen konnte, unterscheiden 
die sich nicht grossartig.
Sehe ich das richtig, dass ich bei RS485 Bit fuer Bit uebertragen muss? 
Zudem sollte doch jeder Teilnehemer am Bus jedes Datenpaket bekommen -> 
nur Broadcast senden? (Wuerde mich nicht weiter stoeren)


Bitte korrigiert wenn ich falsch liege. :)

Autor: Jens (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe genau das gemacht als Midi-Steuerung. Die ist total unanfällig, 
wenn Du Optokoppler nimmst.

Also mit TxD und evtl. einem Treiber (Transistor) raus und vor jeden 
Slave einen Optokoppler und dann wieder in RxD rein. Die Eingänge der 
Optokoppler sind beim Master zusammengeführt und daher alle parallel 
geschaltet.

Jeder Slave bekommt die gleichen Daten, mit einem ersten Byte wählt man 
den Slave an (dieser entscheidet per Software oder dip ob er der 
richtige ist), für den die Information gilt. Man kann auch "absprechen" 
das eine Nummer bedeutet: Befehl für alle. Ähnlich des Midikanals und 
der Controllerwerte.

Der 485 funktioniert auch sehr gut, habe ich auch schon verwendet. Aber 
letztendlich alles über die USART.

Die Störanfälligkeit ist gering: 485, da beide Leitungen Störungen 
"gegenphasig" kompensieren. Bei MIDI handelt es sich um eine 
Stromverbindung, wenn ein Impuls gesendet wird fließt ein gewisser 
Strom  (2mA?),  kurzzeitig.

Autor: Chris L. (hazdur)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jens (Gast) schrieb:
>Also mit TxD und evtl. einem Treiber (Transistor) raus und vor jeden
>Slave einen Optokoppler und dann wieder in RxD rein. Die Eingänge der
>Optokoppler sind beim Master zusammengeführt und daher alle parallel
>geschaltet.

Hoert sich sehr interessant an. Leider ist mir noch nicht ganz klar, 
welcher Ausgang vom Optokoppler nun mit was verbunden ist. Die Eingaenge 
der Optokoppler beim Master zusammenfuehren ist klar. Aber welche 
Ausgaenge vom OK genau an welchens TxD und RxD??

Welches Protokoll hast du dabei genutzt? RS232 wuerde ich jetzt 
vermuten.

Autor: Jobst M. (jobstens-de)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Chris L. schrieb:
> TWI:
> Ich kann ja jedem Slave ein eigene Adresse zuweisen (TWA Register bei
> den AVRs). Wenn ich jedem Slave die gleiche TWI-Adresse zuweisen wuerde
> und der Master an diese Adresse sendet, dann sollten ja ansich alle
> Slave die Daten bekommen (Broadcast). Falls soweit richtig:
>  - Wuerde das dann nicht Probleme mit dem internen TWI-Management geben?
>  - Jeder Slave sollte doch entsprechend ein ACK zuruecksenden, wenn
> dieser zum Empfang von Daten bereit ist.
>  - Der Master wuerde es vermutlich nicht mitbekommen, wenn ein Slave
> kein ACK gesendet hat -> ein Slave bekommt die Nachricht nicht?

Bei TWI (aka I²C) gibt es eine Broadcast-Adresse, auf die alle Chips 
reagieren. Ob diese überhaupt mit ACK quittiert wird, weiß ich gerade 
nicht.
Das Problem, nicht sicher alle zu erreichen, hast Du mit Broadcasts 
immer. Wenn Du von jedem Empfänger einzeln ein Quittung haben möchtest, 
mußt Du ihn einzeln ansprechen.


Gruß

Jobst

Autor: Weingut Pfalz (weinbauer)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Chris L. schrieb:
> Welches Protokoll hast du dabei genutzt? RS232 wuerde ich jetzt
> vermuten.

RS232 ist kein Protokoll, sondern der physikalische Übertragungsweg.
Das Protokoll ist eine Schicht darüber.
Das Protokoll juckt es nicht wie die Daten physikalisch übertragen
werden, sondern nur dass (!) Daten übertragen werden und was damit 
gemacht werden soll.

Autor: Daniel Steffen (derdaniel)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also alles was Du da so beschreibst passt perfekt auf ein TWI/I2C-System 
mit entweder niedrigen Taktraten oder Treibern (P82B96 ist da das 
Stichwort).

Broadcastfähig
experimentelle Kabellängen über 100m
Multimasterfähig
Hot-Pug/-Unplugfähig
Acknowledgement
uvm.

http://www.nxp.com/documents/user_manual/UM10204.pdf sind die Specs vom 
I2C-Bus da kannste alles nochma genau nachschmökern...

Autor: Knut Ballhause (Firma: TravelRec.) (travelrec) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Chris L. schrieb:
> Sehe ich das richtig, dass ich bei RS485 Bit fuer Bit uebertragen muss?

Das macht Deine Hardware-UART, insofern der Controller eine hat. 
Ansonsten halt Software.

Autor: Jens (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Wenn Du nur ca 5 Slaves hast, kannst Du das ohne Treiber machen.

Das Protokoll kannst Du Dir selbst ausdenken.

Ich würde ein Midi ähnliches verwenden.

Schicke das erste Byte mit Bit7 = 1, also > 127
Die folgenden Bytes haben alle Bit7 = 0, gehen dann nur bis 127, da Du 
nur Bit6..Bit0 nutzen kannst.

Also z.B.

1xxxxxxx  0xxxxxxx 0xxxxxxx usw.

Damit bekommst Du raus, wann eine Übertragung beginnt. Das 1. Byte 
benutzt Du als Adressbytes z.B. 10000001 für Slave1. Du kannst den Block 
von x Bytes alle hintereinander senden mit der entsprechenden 
Senderoutine.

Autor: Knut Ballhause (Firma: TravelRec.) (travelrec) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jens schrieb:
> Schicke das erste Byte mit Bit7 = 1, also > 127
> Die folgenden Bytes haben alle Bit7 = 0, gehen dann nur bis 127, da Du
> nur Bit6..Bit0 nutzen kannst.

Was ein Quark, der AVR kann 9-Bit Frames generieren, wobei das 9te Bit 
(Bit8) für die Adressierung genutzt wird. Damit sind volle 8 Bit für 
Adressen und Daten möglich, bei den Adressen ist das neunte Bit = 1, bei 
den Daten ist das neunte Bit = 0. Dafür jetzt MIDI und Optokoppler zu 
verbasteln, ist reine Verschwendung.

Autor: Jens (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Midi ist ein Standart, wo es ein Haufen Software gibt zum Simulieren und 
Probieren und der Optokoppler ist wichtig, wenn Du lange Kabelstrecken 
hast.
Außerdem geht es auch ums Verständnis und ich hab es erfolgreich in der 
Praxis eingesetzt.

Aber es muss ja solche klugen Menschen wie Knut geben, sonst würde es ja 
zu einfach werden.

Autor: Jürgen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also das mit den Optokopplern ist aus meiner Sicht die bisher beste und 
preiswerteste Lösung. Kein Can-Bibliotheken, keine teuren ICs, 
galvanische Trennung inclusive. Ich habe hier sowas ähnlichens für einen 
Datenlogger gemacht, nur in der anderen Richtung. Da sind ein paar 100m 
Kabel in wilder Stern-Topologie verbaut. Läuft mit 1200 Baud 
anstandslos. Kommt natürlich auf die gewünsche Geschwindigkeit an. I2C 
ist für den zweck denke ich die schlechteste der diskutierten Varianten. 
Der Hinweis auf Midi und die Technik mit dem gesetzen Bit für Befehle 
ist auch sehr brauchbar und bewährt. Auf die 9bit Variante würde ich 
nicht gehen, da verbaut man sich sonst die Möglichkeit das direkt über 
eine rs232 vom PC zu steuern.

Autor: Jobst M. (jobstens-de)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jens schrieb:
> Midi ist ein Standart, wo es ein Haufen Software gibt zum Simulieren und
> Probieren

Und das 9-Bit-UART-Protokoll ist schon in Hardware vorhanden. SW gibt es 
dafür auch.


> und der Optokoppler ist wichtig, wenn Du lange Kabelstrecken
> hast.

Quark. Die sind bei MIDI eingebaut, um keine Brummschleifen zu erzeugen.


> Aber es muss ja solche klugen Menschen wie Knut geben, sonst würde es ja
> zu einfach werden.

Sagen wir mal so: Es gibt Menschen, die es sich nicht unnötig 
kompliziert machen :-)


Gruß

Jobst

Autor: Chris L. (hazdur)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Vielen Dank fuer den gesamten Input! Nach und nach kommt fuer mich mehr 
Licht in die Geschichte - meine ich zumindest. ;)

Wenn ich die AVRs untereinander mit der geschilderten Loesung von Jens 
(http://www.mikrocontroller.net/attachment/97095/Midi_Bus.gif) verbinde, 
dann sollte es doch moeglich sein, die Daten ueber die eingebaute 
HW-UART zu verschicken? Dies koennte man dann ja mit den Routinen aus 
dem AVR Tutorial sehr einfach realisieren.
Wie die uebertragenen Daten dann schlussendlich von den Slave-uC 
behandelt werden, bleibt ja mir ueberlassen.


Jens schrieb:
>Schicke das erste Byte mit Bit7 = 1, also > 127
>Die folgenden Bytes haben alle Bit7 = 0, gehen dann nur bis 127, da Du
>nur Bit6..Bit0 nutzen kannst.

>Also z.B.

>1xxxxxxx  0xxxxxxx 0xxxxxxx usw.

>Damit bekommst Du raus, wann eine Übertragung beginnt. Das 1. Byte
>benutzt Du als Adressbytes z.B. 10000001 für Slave1. Du kannst den Block
>von x Bytes alle hintereinander senden mit der entsprechenden
>Senderoutine.

In meinem Fall soll ein Datensatz ja immer 4 Byte betragen. Somit 
koennte man doch in den Slaves mitzaehlen, wie viele Bytes uebertragen 
wurden und jeweils nach vier Bytes einen neuen Datensatz erwarten. Somit 
waere es dann auch nicht noetig ein Bit zu reservieren, wodurch man alle 
8 Bit nutzen koennte.
Dies jetzt allerdings nur fuer meinen Fall. Ansonsten wird das ja bei 
dem Midi-Protokoll so gehandhabt.

Autor: Jobst M. (jobstens-de)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Chris L. schrieb:
> In meinem Fall soll ein Datensatz ja immer 4 Byte betragen. Somit
> koennte man doch in den Slaves mitzaehlen, wie viele Bytes uebertragen
> wurden und jeweils nach vier Bytes einen neuen Datensatz erwarten. Somit
> waere es dann auch nicht noetig ein Bit zu reservieren, wodurch man alle
> 8 Bit nutzen koennte.

Das ist nur blöd, wenn sich einer der Slaves, z.B. durch einen 
Störimpuls, verzählt. Der hat keine Chance wieder Anschluss zu finden.

Was einen dann gleich zur 2. Sache bringt: Wie sicher müssen die Daten 
beim Empfänger ankommen? Ist es egal, wenn mal ein paar Bytes fehlen 
oder hängen von jedem Byte Menschenleben ab? :-) Muss der Slave eine 
Prüfsumme bilden und diese mit dem Master abgleichen?


Gruß

Jobst

Autor: Chris L. (hazdur)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jobst M. (jobstens-de) schrieb:
>Das ist nur blöd, wenn sich einer der Slaves, z.B. durch einen
>Störimpuls, verzählt. Der hat keine Chance wieder Anschluss zu finden.

In der tat, waere eher so mittel...


>Wie sicher müssen die Daten beim Empfänger ankommen? Ist es egal, wenn
>mal ein paar Bytes fehlen oder hängen von jedem Byte Menschenleben
>ab? :-)

Menschenleben haengen davon definitv nicht ab. :)
Kommen Daten bei einem Slave "falsch" an, dann wird der nicht 
explodieren oder sonstiges, nur die Ausfuehrung waere in diesem Sinne 
fehlerhaft. Kurz: Bringt niemanden um, waere aber unschoen.


>Muss der Slave eine Prüfsumme bilden und diese mit dem Master abgleichen?

Ist bisher nicht geplant. Nur Kommunikation vom Master zu den Slaves. 
Kein Slave -> Master oder Slave -> Slave.


Vllt. ist es noch wichtig zu sagen, dass das System innerhalb einer 
"Standart"-Wohnung betrieben werden soll. Stoereinfluesse waeren daher 
"nur" Stromkabel in den Waenden, Handy-, Radio- und W-Lan Signale und 
was da sonst noch alles so rumschwirrt. Aber keine 100kV Leitungen etc..

Autor: Knut Ballhause (Firma: TravelRec.) (travelrec) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jens schrieb:
> Midi ist ein Standart, wo es ein Haufen Software gibt zum Simulieren und
> Probieren und der Optokoppler ist wichtig, wenn Du lange Kabelstrecken
> hast.
> Außerdem geht es auch ums Verständnis und ich hab es erfolgreich in der
> Praxis eingesetzt.

MIDI ist eine 2-Punkt-Verbindung für Musikinstrumente. Diese 
Schnittstelle als BUS zu vergewaltigen, ist nicht nur unsinnig, sondern 
auch unzuverlässig. Jeder Optokoppler braucht Strom. Bei 20 Slaves 
kommen wir in einen Bereich von 200mA Steuerstrom für eine Richtung. Da 
müssen dann aber schon ganz nette Treiber am Werk sein. Bei hohen 
Strömen im Kabel gibt es auch ordentliches Übersprechen auf den 
Rück-Kanal. Ich denke, das ist eine Spur am Ziel vorbei. MIDI ist per 
Spezifikation auch lediglich für 5m-Kabellänge entwickelt worden. Klar 
geht mehr, ist aber ausserhalb der Spezifikation.

Autor: Jobst M. (jobstens-de)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Knut Ballhause schrieb:
> MIDI ist eine 2-Punkt-Verbindung für Musikinstrumente. Diese
> Schnittstelle als BUS zu vergewaltigen, ist nicht nur unsinnig, sondern
> auch unzuverlässig.

Dafür gibt es doch die 'THRU' Buchse :-)

> Bei hohen Strömen im Kabel gibt es auch ordentliches Übersprechen
> auf den Rück-Kanal.

MIDI hat ja gar keinen Rückkanal :-D
Das wird im Ring gelegt.


Gruß

Jobst

Autor: Jobst M. (jobstens-de)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Chris L. schrieb:
>>Muss der Slave eine Prüfsumme bilden und diese mit dem Master abgleichen?
>
> Ist bisher nicht geplant. Nur Kommunikation vom Master zu den Slaves.
> Kein Slave -> Master oder Slave -> Slave.

Aber der Master kann eine Prüfsumme mitschicken und der Slave sie 
vergleichen.

Chris L. schrieb:
> Vllt. ist es noch wichtig zu sagen, dass das System innerhalb einer
> "Standart"-Wohnung betrieben werden soll. Stoereinfluesse waeren daher
> "nur" Stromkabel in den Waenden, Handy-, Radio- und W-Lan Signale und
> was da sonst noch alles so rumschwirrt. Aber keine 100kV Leitungen etc..

(... und Waschmaschine, Microwelle, Heizung, ...)

Kann auch schon ausreichen. Das ist aber nicht das Problem.
Das Problem ist, daß Du Dir Gedanken darüber machen musst, wie damit 
umgegangen werden soll, wenn es mal passiert.

Sollen Fehler entdeckt werden?
 Nein: Mit fehlerhaften Daten arbeiten.
 Ja: Wie soll darauf reagiert werden?
  Daten verwerfen.
  Daten mittels Prüfcodes zurückrechnen (z.B. Hammingcode).
  Zwischenwerte errechnen.
  Sich komplett abschalten.
  Darauf warten, daß das Paket nochmal gesendet wird.



Gruß

Jobst

Autor: Jens (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Wieviel Slaves sind es denn?
Bei 20 Stück würde ich auch den 485er Bus nehmen. Da gibt es fertige 
8pin ICs, die man direkt an RxD und TxD anschließen kann - geht prima.

5m bei Midi sollte man ignorieren - ich habe sehr sichere Anlagen gebaut 
mit über 20m Kabel, auch im Freien.

Optokoppler (die im übrigen auch beim 485er Bus anzutreffen sind) haben 
für mich schon noch einen Vorteil. Kleine Störspannungen bringen die Led 
nicht zum Leuchten, sondern nur klare Impulse. Die Schaltschwelle ist 
nicht so empfindlich. Bei mittleren Baudraten ist das o.k..

Zum Protokoll. Ich weiß ja nicht was zu übertragen ist. Reserviere 
einfach ein Byte oder eine Bytefolge, die sonst nicht vorkommt, als 
Codewort.

Also z.B. FF AA BB CC --- erst wenn der Slave dieses Wort erkannt hat, 
wertet er nachfolgende Bytes aus. Bei jedem ankommenden FF prüft er, ob 
das Codewort AA BB CC ist usw..

Autor: spess53 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

>Bei 20 Stück würde ich auch den 485er Bus nehmen. Da gibt es fertige
>8pin ICs, die man direkt an RxD und TxD anschließen kann - geht prima.

Alternativ kann man auch CAN-Bustreiber (PCA82C250 und Konsorten) 
nehmen. Geht noch besser, da man sich nicht um die 
Sende/Empfangs-Umschaltung kümmern muss.

>Also z.B. FF AA BB CC --- erst wenn der Slave dieses Wort erkannt hat,
>wertet er nachfolgende Bytes aus. Bei jedem ankommenden FF prüft er, ob
>das Codewort AA BB CC ist usw..

Wozu? Die USARTs der AVR haben einen Multiprozessormode. Da kann jeder 
Slave mit einer Adresse angesprochen werden.

MfG Spess

Autor: Ulli (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
spess53 schrieb:
> Hi
>
>>RS485 ist wohl nicht der Weissheit letzter Schluss, da:
>>Keine Sterntopographie
>>Keine Stichleitungen
>
> Dann lies mal hier:
>
> www.national.com/an/AN/AN-1057.pdf
>
> MfG Spess

Na so was ... das habe ich von hier:

http://www.mikrocontroller.net/articles/RS-485

Man sollte doch meinen, dass es irgendwo ein Bus-System gibt, welches 
problemlos zu handhaben und gleichzeitig einfach auf zu bauen ist.
Dieser Thread beweist das Gegenteil .....

MfG
Ulli

Autor: spess53 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

>Na so was ... das habe ich von hier:
>http://www.mikrocontroller.net/articles/RS-485

Man sollte halt keine Second-Hand-Quellen verwenden.

>Man sollte doch meinen, dass es irgendwo ein Bus-System gibt, welches
>problemlos zu handhaben und gleichzeitig einfach auf zu bauen ist.
>Dieser Thread beweist das Gegenteil .....

Die sinnd alle problemlos, wenn man weiß, was man macht. Und kompliziert
aufzubauen sind alle hier erwähnten Busse auch nicht.

MfG Spess

Autor: Lars Hufnagel (hufnala)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,
bin mir nicht sicher ob ich was übersehen habe, aber LIN kommt auch in 
Frage. Ich denke es gibt AVRs mit LIN und der Transceiver sind nur ein 
paar Transistoren und Widerstände.

Lt. Standard allerdings nur bis 20kBit/s, Checksumme usw. ist 
standardisiert. 5m sicher kein Problem und ich vermute C-Beispiele 
gibt's auch mehrere. Letztendlich baut das ganze auf UART auf, nur dass 
dann nur eine Leitung für die Übertragung genutzt wird - ggf. durch 
Master/Slave Frames sogar bidirektional.

Da meines Wissens keine exakte Busabstimmung erforderlich ist, können 
die Slaves auch in begrenztem Umfang flexibel gehalten werden, ich 
wüsste nicht was Plug&Play entgegenspricht.

Allerdings : LIN Funktioniert wie CAN signalbezogen, d.h. der Master 
sendet und die Slaves schauen sich an ob sie die Information 
interessiert und verarbeiten diese - das entspricht nicht ganz Deiner 
Anforderung. Über "Diagnose" und TP ist aber auch eine 1:1 Kommunikation 
möglich.

Schau für Details auch mal unter http://www.lin-subbus.org

//hufnala

Autor: Knut Ballhause (Firma: TravelRec.) (travelrec) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jobst M. schrieb:
> Dafür gibt es doch die 'THRU' Buchse :-)

Jobst M. schrieb:
> MIDI hat ja gar keinen Rückkanal :-D
> Das wird im Ring gelegt.

Das erzählst Du einem Musiker!? ;-)
Nein, ich bezog mich auf das, was der OP damit machen sollte, nämlich 
einen BUS...

Jens schrieb:
> Optokoppler (die im übrigen auch beim 485er Bus anzutreffen sind)

Habe noch nie Optokoppler bei RS485 gesehen. Wenn doch, war es kein 
RS485.


Ulli schrieb:
> Man sollte doch meinen, dass es irgendwo ein Bus-System gibt, welches
> problemlos zu handhaben und gleichzeitig einfach auf zu bauen ist.
> Dieser Thread beweist das Gegenteil .....

RS485 ist einfach. Es liegt am Thread.

Autor: Knut Ballhause (Firma: TravelRec.) (travelrec) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Lars Hufnagel schrieb:
> aber LIN kommt auch in
> Frage.

Nicht auch noch LIN...

Lars Hufnagel schrieb:
> Ich denke es gibt AVRs mit LIN

Nope. Nur für Automotive-Buden oder noch nicht am Markt. Wozu auch.

Autor: Jürgen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wer den "Mutiprozessormode" der AVR Uarts schon mal eingesetzt hat, 
weiss, dass da nicht viel zu sparen ist. Ein paar Interupts vielleicht 
aber mehr nicht. Solange nicht Highspeed im Mittelpunkt steht völlig 
irrelevant. Hier ging es wirklich von Abfang an nur um eine! Richtung. 
Und um den Hobbybereich und nicht im AKW. Was sollen dann da die ganzen 
anderen Busse wie i2c, Lin, Can u.s.w. Irgendwann kommt jemand noch mit 
Ethernet. Alles was man sich an fremden Libs mit ins Boot holt, muss man 
verstehen oder fällt irgendwann darauf rein. Also wenn es nicht nötig 
ist, dann lieber die paar Bytes mit den wirklich einfachen UART-Befehlen 
versenden und gut. Manchmal denke ich hier sind welchen aus dar 
Architekten-Branche mit dabei, für die gilt ja bekanntlich: je mehr es 
kostet desto mehr bleibt für einen selbst übrig. Ein paar Wald- und 
Wiesen- Transitoren oder Optokoppler hat jeder in der Kiste, und mehr 
braucht man für diesen Anwendungsfall nicht. Wenn die galvanische 
Trennung nützlich ist, dann Optokoppler, wenn nicht dann eben direkt. Je 
schneller es gehen soll, desto niederohmiger muss das werden. Mehr 
nicht.

Autor: Chris L. (hazdur)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Leute,

da ich gerade das Gefuehl habe, dass dieses Thema etwas den Rahmen 
sprengt - fuer mich zumindest - hier nochmal eine kurze Zusammenfassung 
meines Vorhabens:

Ich moechte eine Bus-Struktur mit AVR-uC aufbauen 
(http://www.mikrocontroller.net/attachment/96944/Concept.png). Dabei 
gibt es einen Master und x Slaves. Jeder Slave hat eine feste Adresse 
(gesetzt per Dip-Schalter). Es gibt nur Kommunikation vom Master zu dem 
Slaves. Kein 'Slave -> Master' oder 'Slave -> Slave'.
Der Master sendet Datenpakete ueber den Bus an die Slaves. Ein 
Datenpaket soll dabei aus 4 Byte bestehen:
 - 1 Byte Adresse
 - 3 Bytes Nutzdaten.

Aufgrund der Bus-Struktur, empfaengt jeder Slave jedes gesendete 
Datenpaket. Bei der Auswertung der Daten entscheidet der Slave, ob die 
Nutzdaten fuer ihn relevant sind oder nicht.
Entfernungen von mehreren Metern zwischen Master und Slave sind 
moeglich.

Nun suche ich ein Bus-System, dass diese Anforderung erfuellt: Einer 
sendet, alle anderen Empfangen. Wobei der Sender(Master) fest gelegt 
ist.

-------------------------------------------------------------

Jens schrieb:
>Wieviel Slaves sind es denn?

Therotisch von einem bis x Slaves. Wobei x nicht einmal durch die Anzahl 
moeglicher Adressen (1 Byte) beschraenkt wird, da es durchaus mehrere 
Slaves mit der gleichen Adresse geben kann.


Jobst M. (jobstens-de) schrieb:
>Sollen Fehler entdeckt werden?

Theoretisch ja, ist aber erstmal nicht soo wichtig. Treten 
Uebertragungsfehler auf, wuerde ich mich um eine entsprechende Codierung 
und Decodierung der Daten kuemmern, wenn die Bus-Struktur aufgebaut ist.


Bisherige Vorschlaege waren:
1. TWI/I2C
2. CAN-Bus
3. RS485 (http://www.mikrocontroller.net/attachment/97159/485.gif)
4. UART + Optokoppler 
(http://www.mikrocontroller.net/attachment/97095/Midi_Bus.gif)
5. LIN-Bus


Zu 1.)
Habe ich bereits etwas drueber gelesen. Ich weiss, dass viele AVRs 
bereits eingebaute HW dafuer mitbringen. In dieser HW, kann man jedem 
AVR eine TWI-Adresse fest zuweisen. Wuerde ich nun jedem Slave die 
gleiche TWI-Adresse zuweisen, wuerde dann jeder Slave jedes Datenpaket 
bekommen?
Allerdings gibt es bei dieser Uebertragungsart - soweit ich weiss - 
einiges an Management im Hintergrund (ACK etc.). Koennten diese 
Management-Sachen nicht irgendwelche Probleme hervorrufen?


Zu 2.)
Kenne ich mich noch nicht wirklich mit aus - habe ich eher nur mal 
gehoert. Wenn ich mir aber das Datenblatt vom PCA82C250 anschaue, 
erscheit es mit so, als ob ich dann "einfach" die Daten ueber den UART 
der AVRs sende und empfange? Der PCA82C250 wandelt die Daten 
entsprechend um, so, dass diese ueber den CAN-Bus gesendet werden 
koennen. Spontan wuerde ich sagen, ich verbinde alle CAN_H und CAN_L 
jedes PCA82C250 miteinander um den Bus aufzubauen? Vermutlich noch ein 
paar Widerstaende dazu.


Zu 3.)
Aehnlich wie 2., nur dass andere Treiber-ICs benutzt werden. In diesem 
Fall z.B. die ICs SN75176A oder MAX485.


Zu 4.)
Bisher die optimistischste Variante. Im Prinzip auch senden und 
empfangen ueber die UARTs der AVRs. Problem war hierbei, dass bei der 
Uebertragung ein gewisser Strom fliesst. Dieser Strom multipliziert sich 
dann mit der Anzahl der Slave und kann gut auf einige 100mA kommen. 
Entsprechende Treiber benoetigt?


Zu 5.)
Hab ich gerade das erste oder zweite Mal gehoert, muss ich zugeben. Kann 
daher noch nicht viel dazu sagen. Aber den bisherigen Beitraegen dazu 
entnehme ich, dass diese Variante nicht unbedingt die "beste" fuere den 
Fall hier ist.


Bitte korrigiert mich.


Ich selber wuerde im Augenblick zu den Varianten 2, 3 oder 4 tendieren. 
Der Vorteil fuer mich ist, dass ich die UARTs der AVRs nutzen kann, wozu 
es gute Tutorials und unmengen an bestehender Software gibt. Nur, kann 
ich mit diesen Systemen auch den entsprecheden Bus aufbauen??


Schoenen Gruss! :)


EDIT: Trotz aller Muehen, die Rechtschreibung zu wahren, habe ich es 
natuerlich im Titel vermasselt. Ich wuerde daher einen Mod bitten, dass 
fehlende "g" bei Bedin(g)'ung im Titel zu ergaenzen. ;)

Autor: spess53 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

>Bitte korrigiert mich.

>Zu 3.)
>Aehnlich wie 2., nur dass andere Treiber-ICs benutzt werden. In diesem
>Fall z.B. die ICs SN75176A oder MAX485.

Der, von dir erwähnte, PCA82C250 ist lediglich ein Bustreiber. Der 
stellt nur die Verbindung zwischen CAN-Bus und CAN-Controller her. 
Letzterer ist für das definierte CAN-Protokoll zuständig.
Ohne CAN-Controller kann man mit den PCA82C250 (o.ä.) auch einen Bus mit 
eigenem Protokoll realisieren. Das ist dann aber kein CAN mehr

RS485 beschreibt lediglich die elektrischen Eigenschaften des Busses. 
Für das Protokoll bist du zuständig.

>Zu 4.)
>Bisher die optimistischste Variante. Im Prinzip auch senden und
>empfangen ueber die UARTs der AVRs. Problem war hierbei, dass bei der
>Uebertragung ein gewisser Strom fliesst. Dieser Strom multipliziert sich
>dann mit der Anzahl der Slave und kann gut auf einige 100mA kommen.
>Entsprechende Treiber benoetigt?

Eher eine exotische Variante. RS454- und CAN-Bustreiber lassen sich
problemlos an der UART eines AVRs betreiben.

MfG Spess



MfG Spess

Autor: Tsmc (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also um mal ein wenig Klarheit zu schaffen. Ihr redet von zwei 
unterschiedlichen Sachen. Man muss beachten dass die Adressierung nichts 
mit dem Physikalischen Medium zu tun hat. So kann man zum Beispiel auch 
ein CAN-Bus mit RS 485 betreiben. Die Bausteine für RS485 und CAN 
benutzen beide Differenzielle Signale mit denen man ein Bus-System 
aufbauen kann. Beide müssen auch am Ende terminiert werden und weisen 
fast die gleichen Eigenschaften auf. Im Prinzip kann die physikalische 
Schnittstelle des CAN-Busses auf unterschiedliche Weise realisiert 
werden. CAN ist mehr im Bereich des Protokolls definiert, dass man mit 
dem AVR dann nachbauen muss. Aber nur weil ich ein CAN Treiber benutze 
heißt dass nicht, das ich nur noch senden muss und der Treiber macht den 
Rest. Der Frame muss immer noch selbst generiert werden oder mit einer 
lib.

Nur weil ein CAN Treiber eingesetzt wird ist es noch kein CAN-Bus. Erst 
das Protokoll macht es dazu.

Die Varianten über CAN, RS845 und Optokoppler sind eigentlich das 
gleiche. Man muss einen Frame über den Uart schicken der dann letztlich 
über eins der drei Varianten versenden wird. Die Sende- und Empfangs- 
Routine musst du immer noch selber programmieren. Und diese machen 
letztlich erst die Adress Verwaltung.

Also Physikalisch sind RS485 und CAN eigentlich die bessere Wahl, da sie 
Störungs- unanfälliger sind. Welches Protokoll du wählst ist dir 
überlassen. Ob du nun mit 8Bit arbeitest oder mit 9Bit für die 
Adressierung. Eine Adresse musst du so oder so senden. Der MPCM hat nur 
den Vorteil das er die Controller die nicht angesprochen sind bei ihrer 
Arbeit nur dann unterbricht wenn eine Adresse gesendet wird aber nicht 
bei Daten. Wenn diese aber in der Zeit so wie so nichts zu tun haben ist 
es egal was du benutzt.

Das CAN Protokoll finde ich jetzt in deinem Fall unnötig. Es würde 
reichen wenn du ein Frame aufbaust mit 7 Byte.

 1 Byte | 4 Byte  | 2 Byte
Adresse |  Daten  |  CRC

Somit hast du alles was du brauchst wobei die CRC mehr oder weniger 
optional ist.

Autor: Chris L. (hazdur)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Tsmc (Gast) schrieb:
>Also um mal ein wenig Klarheit zu schaffen. Ihr redet von zwei
>unterschiedlichen Sachen. Man muss beachten dass die Adressierung nichts
>mit dem Physikalischen Medium zu tun hat.

Gut, das ist mir nun soweit klar. Mir geht es zur Zeit erstmal um das 
physikalische Medium, ueber das ich Bits vom Master zu den Slave 
uebertragen kann.


Tsmc (Gast) schrieb:
>Die Varianten über CAN, RS845 und Optokoppler sind eigentlich das
>gleiche. Man muss einen Frame über den Uart schicken der dann letztlich
>über eins der drei Varianten versenden wird. Die Sende- und Empfangs-
>Routine musst du immer noch selber programmieren.

Dazu kann man doch dann die HW-UART der AVRs nutzen? Ansteuern tut man 
diese natuerlich mit Software. Als Beispiel die Funktionen aus dem 
AVR-Tutorial: 
http://www.mikrocontroller.net/articles/AVR-Tutori... 
und 
http://www.mikrocontroller.net/articles/AVR-Tutori...


Tsmc (Gast) schrieb:
>Und diese machen letztlich erst die Adress Verwaltung.

Was ist mit dieser "Adressverwaltung" genau gemeint? Kuemmert es die 
UART-HW welcher uC seine Daten empfaengt?


Tsmc (Gast) schrieb:
>Welches Protokoll du wählst ist dir überlassen.

Da hatte ich mir mein 4 Byte Ding ausgedacht (1 Byte Adresse, 3 Byte 
Nutzdaten). Optional natuerlich noch irgendwelche Checks, ob die Daten 
OK sind.


Tsmc (Gast) schrieb:
>Eine Adresse musst du so oder so senden. Der MPCM hat nur
>den Vorteil das er die Controller die nicht angesprochen sind bei ihrer
>Arbeit nur dann unterbricht wenn eine Adresse gesendet wird aber nicht
>bei Daten. Wenn diese aber in der Zeit so wie so nichts zu tun haben ist
>es egal was du benutzt.

Kann ich die Multi-Prozessor-Kommunikation nicht einfach aus lassen? Es 
soll mir ja recht sein, wenn jeder Slave jede Nachricht erst einmal 
bekommt und dann entscheidet was er mit den Daten macht.


Tsmc (Gast) schrieb:
>Es würde reichen wenn du ein Frame aufbaust mit 7 Byte.

> 1 Byte | 4 Byte  | 2 Byte
>Adresse |  Daten  |  CRC

Wofuer ist bei diesem Beispiel genau die Adresse gedacht? Wann soll die 
womit verglichen werden?



Vielen Dank und einen schoenen Gruss. :)


P.S.: Bin das Wochenende ueber weg. Werde somit vermutlich erst wieder 
am Dienstag hier reinschauen.

Autor: Tsmc (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Chris L. (hazdur) schrieb:
>Dazu kann man doch dann die HW-UART der AVRs nutzen?

Genau für diese Varianten kannst du den HW-UART nutzen.

Chris L. (hazdur) schrieb:
>Da hatte ich mir mein 4 Byte Ding ausgedacht (1 Byte Adresse, 3 Byte
>Nutzdaten). Optional natuerlich noch irgendwelche Checks, ob die Daten
>OK sind.

Das Protokoll das du dir ausgedacht hast ist im Prinzip OK. Ist halt 
ohne Fehlerüberprüfung.

Chris L. (hazdur) schrieb:
>Kann ich die Multi-Prozessor-Kommunikation nicht einfach aus lassen? Es
>soll mir ja recht sein, wenn jeder Slave jede Nachricht erst einmal
>bekommt und dann entscheidet was er mit den Daten macht.

Natürlich kannst du ihn auslassen. Jeder Teilnehmer Empfängt dann halt 
alles, ob es nun eine Adresse ist oder Daten die vielleicht auch gar 
nicht für ihn bestimmt sind. Natürlich kannst du dann die Daten immer 
noch verwerfen. Der Vorteil ist einfach nur wenn auf einem Bus viele 
Daten gesendet werden, wird jeder Teilnehmer damit belastet und muss 
seine Arbeit unterbrechen. Wenn du allerdings den Empfang per Polling 
machst spiel dies keine Rolle da dein Controller so wie so immer den 
Uart prüft. Es hat halt nur Auswirkung wenn du den Empfang mit Interrupt 
machst. Dann bekommt dein Controller für jedes Byte ein Interrupt. Aber 
wie schon gesagt wenn dein Controller nur etwas machen wenn er einen 
Befehl bekommt (z.B.: ein Lampe ein/aus schalten) dann ist es völlig 
egal.

Chris L. (hazdur) schrieb:
>Wo für ist bei diesem Beispiel genau die Adresse gedacht? Wann soll die
>womit verglichen werden?

Die Adressverwaltung die bei diesen Varianten sind alle Software 
basierend auch beim MPCM. Du musst also in deinem Programm die 
Zieladresse im Frame mit der Adresse deines Slaves vergleichen damit der 
Slave weis ob er gemeint ist oder nicht. Dies hast du ja auch ein deinem 
Protokoll so vorgesehen. Ich hatte halt 4 Daten Bytes vorgesehen statt 3 
Byte wie du.

Autor: Lars Hufnagel (hufnala)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi Knut,
warum so negativ hab ich Dir was getan?

Knut Ballhause schrieb:

> Nicht auch noch LIN...
Warum denn nicht? Geht einfacher klar, aber bietet Standards wie 
Checksummen etc. und ein relativ einfaches 2 Leitungsinterface (Data & 
Gnd) und ein relativ störsicheres Übertragungsverhalten, oder nicht? 
Soweit ich das kenne ist nicht mal Schirmung oder Twistet pair wirklich
erforderlich (umgebungsabhängig?).

>> Ich denke es gibt AVRs mit LIN
>
> Nope.
sry : http://www.atmel.com/dyn/products/devices.asp?family_id=607
behauptes was anderes:
The ATtiny87 : provides the following features: 8KB of In-System 
Programmable Flash, 512 bytes EEPROM, 512 bytes SRAM, 6 general purpose 
I/O lines, 32 general purpose working registers, one 8-bit Timer/Counter 
with compare modes, one 8-bit high speed Timer/Counter, Universal Serial 
Interface, a LIN controller, Internal and External Interrupts, a 
4-channel, 10-bit ADC, a programmable Watchdog Timer with internal 
Oscillator, and three software selectable power saving modes.

>Nur für Automotive-Buden
Es gibt lt. Atmel auch noch die Automotive Variante ATtiny87 AUTO 
Unterschiede habe ich mir nicht angesehen (TempBereiche, 
Lagerfähigkeiten, Stromverbrauch, kann vieles sein)...

>oder noch nicht am Markt.
Yep, keine Verfügbarkeit, also eher theoretisch, konnte ich ja nicht 
ahnen.

>Wozu auch.
Um mehere uC einfach miteinander über LIN zu verbinden ;-) ?

Aktuell finde ich keine gewünschte Datenrate (überlesen?) und keine 
echte Länge("meherere Meter", überlesen?). Ob das mit RS485 funktioniert 
und welchen Aufwand Plug&Play von Slaves a.d. STelle physikalisch 
bedeutet weiss ich nicht und habe daher nichts dazu beizutragen. Mit LIN 
geht das alles soweit ich weiß in einem bestimmten Rahmen. Welchen 
Aufwand das bzgl. der Lib/dem Speicher bedeutet weiß ich nicht (LIN 
Beiträge gibts ja mehrere im Forum - jetz kennt Chris den Bus kann 
selber schauen) aber physikalisch ist das mit weniger Aufwand als CAN 
oder ETH wie ziemlich weit oben beschrieben zu realisieren...

Auswählen muss Chris es eh selber, ob es für seine Anwendung passt kann 
nur er entscheiden.

Also bitte als Hinweis verstehen, Danke...

In diesem Sinne schönen Abend
//hufnala

Autor: Chris L. (hazdur)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Tsmc (Gast) schrieb:
>Das Protokoll das du dir ausgedacht hast ist im Prinzip OK. Ist halt
>ohne Fehlerüberprüfung.

Klar ist das nicht DAS Protokoll, gebe ich dir vollkommen recht. Ist 
bisher nur ein erster Entwurf, den ich mir mal ausgedacht habe. 
Gewohnheitsmaessig sieht es dann bei der Realisierung eh anders aus. ;)


Tsmc (Gast) schrieb:
>Die Adressverwaltung die bei diesen Varianten sind alle Software
>basierend auch beim MPCM. Du musst also in deinem Programm die
>Zieladresse im Frame mit der Adresse deines Slaves vergleichen damit der
>Slave weis ob er gemeint ist oder nicht. Dies hast du ja auch ein deinem
>Protokoll so vorgesehen. Ich hatte halt 4 Daten Bytes vorgesehen statt 3
>Byte wie du.

Vielen Dank, habe ich soweit verstanden.


Lars Hufnagel (hufnala) schrieb:
>Aktuell finde ich keine gewünschte Datenrate (überlesen?) und keine
>echte Länge("meherere Meter", überlesen?).

Nein, du hast nichts ueberlesen. Es ist mein erstes Porjekt, bei dem ich 
uC miteinander "vernetzen" moechte. Mein Wissen bzgl. des "Vernetzens" 
ist daher noch sehr rar. Da das Projekt bisher (fast) nur in meinem Kopf 
existiert, kann ich auch noch keine genauen Werte nennen. Bzgl. der 
Laenge kann ich aber sagen, dass es sich im Bereich von 5 - max. 30 m 
halten wird.


Lars Hufnagel (hufnala) schrieb:
>...jetz kennt Chris den Bus kann selber schauen

In der tat, vielen Dank, das werde ich tun. :)


Lars Hufnagel (hufnala) schrieb:
>Auswählen muss Chris es eh selber, ob es für seine Anwendung passt kann
>nur er entscheiden.

Vielen Dank an alle dafuer! Auf meine Frage habe ich nun die 
entsprechenden Antworten und kann alleine weiter machen. Welches 
physikalische Medium ich jetzt genau verwenden werde, weiss ich noch 
nicht. Wo ich mir aber sicher bin, ist, dass ich das Protokoll gerne 
selber "entwickeln" oder gestalten moechte, um es meinen Beduerfnissen 
anpassen zu koennen.



Ich bin aber dennoch offen fuer weitere Ideen und Vorschlaege. :)

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.