mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Alternativen beim AVR-Vernetzten?


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

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich möchte die Pulslängen eines 8 Kanal Modellbauempfängers in Byte
umwandeln und diese dann digital an 8 Atmega8 weitergeben. Die MC
sollen aber auch miteinander komunizieren können (eventuel über einen
Server). Ich habe mir die folgende Möglichkeit überlegt:
Ein MC arbeitet als Server und wandelt die Pulsweiten-Signale des
Modellbausenders in Bytes um und verschickt diese zuerst an den ersten
MC. Dieser antwortet gleich nach dem er den Datenpacket erhalten hat.
Diese Antwort kann dann nun von dem Server an die restlichen MCs
verteilt werden (siehe Anhang).

Ich bin ganz zuversichtlich, dass ich das so hinbekommen kann. Was ich
aber gerne wissen würde, welche Alternativen ich noch zu diesem Aufbau
hätte: Eignet sich etwa der TWI besser für diesen Zweck?

Gruß
Zoltan

Autor: leo9 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gehts dir ums vernetzen als Selbstzweck?
Was willst du hintnach steuern dass du die Rechenleistung von vier uPs
brauchst, wäre es nicht einfacher alles von einem uP erledigen zu
lassen?

grüsse leo9

Autor: Zoltan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die µP sind in einem U-Boot eingebaut, und ich bin froh wenn ich mit
vier Stück auskomme: Fahrtrgeler, Schaltkanal dekodierer,
Tauchtanksregelung, Teifenregelung...
Nun ist aber ein Drucksensor z.B. an die Tiefenregel-µP angeschlossen.
Den Wert könnte ich aber auch bei der Tauchtankregelung gut gebrauchen,
deswegen möchte ich alle µP miteinander Vernetzen.

Autor: Frank Linde (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hhm, das klingt alles nach relativ langsamen Prozessen. Wo genau siehst
Du hier Schwierigkeiten das auf einem Controller zu realisieren?

Gruß, Frank

Autor: Zoltan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ihr habt Recht, einige der oben gennanten Beispiele ließen sich auch auf
einem µP unterbringen. Aber auf keinen Fall reicht ein einziger
Prozessor aus.
Z.B: wäre das eine der Aufgaben:
http://ngrad.bei.t-online.de/Bilder/Steuerplatine.jpg
Der ATMEGA8 muss in dem Fall eine LCD versorgen, Pulslängen dekodieren,
vier Analogwerte messen. Ich kann mir nicht vorstellen, wie ich noch
einen Inkrementalgeber mit dem µP erfassen könnte. Es wäre nicht mehr
gewährleistet, dass sich Interrupts nicht gegenseitig in die Quere
kommen. Im schlimmsten Fall könnte der µP einen Takt des
Inkrementalgebers vepassen.

Meine Frage bleibt also immer noch, welche Alternativen ich zu dem
Vernetztungs-Beispiel oben noch haben könnte.

Gruß
Zoltan

Autor: Frank Linde (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Na, ja, mußt Du selber wissen, Du kennst die zeitlichen Ansprüche, aber
ich sehe mehr Probleme bei Deinem geplanten Netzwerkbetrieb auf Dich
zukommen, als bei dem Versuch, alles in einem Controller zu
realisieren. Als Vernetzungsalternative könntest Du Dir mal I2C bzw.
TWI (ist das Gleiche, nur unter verschiedenen Namen) ansehen. Es
handelt sich um ein serielles Bussystem bis max. 400 kHz.

Gruß, Frank

Autor: Nik Bamert (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wieso nimmst du nicht einfach einen anderen AVR? z.b. einen
atmega128?....

Autor: Zoltan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also gut, ich werde als erstes versuchen möglichst viele Aufgaben auf
einen µC unterzubringen. Aber das Problem bleibt immer noch, dass ein
µC zeitlich von den vielen Ereignissen überfordert wird. Da bringt mir
auch der größere Mikrokontroller (wie der Atmega128 zum Beispiel) auch
nichts.
Ich werde mich mal dann mit dem TWI auseinandersetzen...

Gruß
Zoltan

Autor: Johannes (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Frank: I2C geht bis 3,4MBit/s, und das schon seit Jahren. Nur die
Atmels packen das noch nicht.

Und was die Mehrprozessorlösung angeht, so ist die oftmals sinnvoller
und weniger zeitaufwendig, als zu versuchen, einen MC so voll wie
möglich zu packen. Auch die Fehleranfälligkeit sinkt meiner Meinung
nach.

Autor: ---- (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Johannes
> I2C geht bis 3,4MBit/s, und das schon seit Jahren.
Spezifiziert ist 100kBit/s und später auch 400kBit/s. Woher hast du
diese Info?

> [Mehrprozessorlösung weniger fehleranfällig]...
Spässle gemacht? ;)

Zoltan soll sich weniger auf sein "Gefühl" verlassen, sondern mal
durchrechnen (oder einfach ausprobieren) wie weit er mit einem AVR
kommt. Mehrfach wurde ja schon angedeutet, daß vermutlich auch ein
einziger AVR seine geforderten Aufgaben übernehmen kann.
Mir kommts aber auch so vor, als gings bei diesem Vernetzen um den
Selbstzweck. Das ist auch in Ordnung, wenn dann nicht versucht wird mit
"seltsamen" Begründungen dies zu rechtfertigen...

----, (QuadDash).

Autor: Zoltan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich weiß nicht warum sich dieser Thread in eine ganz andere Richtung
entwickelt, wie eigentlich die Fragestellung war. Ich wollte doch nur
wissen, wie ich einen Netzwerk (Abstand max 2m, Baud 76,8 oder
schneller) zwischen mehreren µC aufbauen kann, und nicht darüber
Diskutieren, wie viele µC ich brauche, um miene Aufgaben zu erfüllen.
Also zum 3x mal für monsieur ohne Namen: Es ist nicht möglich, alles
mit nur einem µC zu erledigen. Und natürlich dient es nur dem
Selbstzweck, es ist ja mein Hobby, und da darf ich mich auch noch an
mein Gefühl verlassen.

Gruß
Zotlan

Autor: Dieter B. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Zoltan

Wenn deine uC Hardware SPI unterstützen und du genug PIN für die CS
Leitungen frei hast, wäre das auch eine Möglichkeit.

Wenn du ein Protokoll verwenden möchtest, wäre SNAP auch eine Lösung.

http://www.hth.com/snap/

Aber wie gesagt, es geht alles I2C, UART, SPI, CAN oder halt was selber
bauen.

Du brauchst die Daten ja auch nur zu senden, wenn sich was geändert
hat. Außerdem kann jeder Chip ja auf Fehler reagieren, wenn eine
Zeitlang gar keine Daten mehr kommen.

MFG
Dieter

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Man muß doch niemanden dazu zwingen, alles mit einer CPU zu machen, nur
weil es möglich ist.

Dazu gehört nämlich schon etwas Erfahrung, mehrere Prozesse so unter
einen Hut zu bringen, daß sie effektiv ablaufen ohne sich gegenseitig
zu stören.


Allerdings ist es wirklich nicht einfach, ein Serverprotokoll zu
implementieren, welches jeden mit jedem verbinden können soll.

Daher würde ich auch zu I2C raten, da das automatisch beliebige
Datenrichtungen zuläßt (Multimaster-Betrieb mit Arbitrierung).

Ich habe sowas schon mal mit 8051-ern programmiert und dabei nur die
Master-Transmitter und die Slave-Receiver Funktion benutzt.


Peter

Autor: Michael (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sofern nicht hohe Reaktionsgeschwindigkeiten gebraucht werden, reicht
es, einen MC als Master und den Rest als Slave zu verwenden. Solch eine
Struktur ist einfach zu programmieren und zu debuggen.

Bei kurzen Leitungen kann man TWI (IIC) nehmen, bei längeren (>50cm)
die USART-Schnittstelle mit MPCM. Bei MPCM schickt der Master als
1.Byte eine Adresse (9.bit gesetzt), die vom Slave automatisch erkannt
wird. MPCM wird von AVR und 8051 unterstüzt.
Der Vorteil von TWI liegt darin, daß der Slave das Protokoll ohne
Interrupt bearbeiten kann; der Nachteil: ein Timeout muß extra
implementiert werden, sonst kann der gesamte Bus hängen.
Beim USART kann man mit Ausnahme der Adressierung gewohnte Routinen
verwenden und mit entsprechenden Schnittstellen längere Entfernungen
überbrücken(RS232/RS485); zur Übertragung kann man z.B. das
Intel-Hex-Format verwenden, was das 'Datenpaket' mit einer einfachen
Prüfsumme absichert.

Eine einzige Aufgabe (Task) pro Prozessor kann die Programmierung sehr
erleichtern: funktioniert einer, dann können auch 20 zusammengeschaltet
werden. Bei kleinen Stückzahlen sind auch die Hardwarekosten
vernachlässigbar. Aber Kosten-Nutzen muß jeder selbst entscheiden.
Soweit mein Senf.

Autor: Zoltan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi Miachael,

Du hast geschrieben, dass die Adresse vom Slave automatisch erkannt
wird. Dies geschieht dann durch die Erkennung des 9. bits. Aber die
Verwaltung und Vergabe der Adressen wird, wenn ich das Datenblatt
richtig verstanden habe, nicht von der Hardware unterstuezt. Weiterhin
kann ich immer nur von dem Master zu den Slaves Daten uebertragen, aber
nicht umgekehrt?

Ich denke, dass ich einen Master haben werde, der nach einander Daten
an die Slaves sendet {Master mit mehreren software UARTs und jeweils
zwei Leitungen an die Slaves, kein BUS }. Wenn der erste Salve einen
Datenpaket erhalten hat, sendet er gleich darauf seine Daten zurueck an
den Master und beginnt mit der abarbeitung seines Programmes. Der
Master verwaltet die empfangenen Daten und verteilt diese an die
anderen Slaves. Anschliessend ruft der Master den zweiten Slave auf,
der antwortet nach erhalt des Datenpackets usw...

Der TWI ist dann wegen der 50 cm Reichweite nicht fuer mich geeignet,
da mache Slaves in 2 m Entfernung zum Master sitzen koennten.

Gruss
Zoltan

Autor: wolli (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn Du sowieso auf Polling-Basis kommunizieren willst, ist das USART
optimal. Mit RS485-Treibern ist die Reichweite auch auf jeden Fall
ausreichend.

Autor: Marcus Maul (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Zlotan,

das Master-Slave Prinzip kann etwas irreführend sein, Master ist immer
der, der sendet, Slave ist der Zuhörer.

Das ganze funktioniert eigendlich relativ einfach, wenn Du Dir mal
folgendes Schema anschaust.

Master sendet Adresse des Slave (9. Bit gesetzt)

ALLE bekommen dieses Packet und nur der, den es betrifft löscht das
Register (frag mich jetzt bitte nicht welches, hab im Moment hier keine
Datenblätter rumliegen, außer MAX485 usw. - Sorry! steht aber in dem
Datenblatt des Atmel unter MPCM) und empfängt somit alle gesendeten
Daten.

Slave sendet ACK oder was auch immer nach Ende aller empfangenen
Daten.

Danach vertauscht Du die Rollen und es geht wieder von oben los.

Wichtig ist nur, das Du immer zuerst die 9. Bit Adresse schickst und
dann die Daten. Damit ist eine Komunikation à la CB-Funk / Amaterfunk
mäglich, aber keine direkte Bidirektionale.

Ein kleines Schmankerl hat die Sache mit der 9.Bit Adresse auch noch.
Wenn Du weniger als 256 Teilnehmer hast, kannst Du über die Adresse
auch bestimmt (Emergency-) Zustände steuern. Meinetwegen 0b11111111 =
Notauftauchen bei einem Uboot oder 0b00001111, alle Motoren aus usw.
Somit sind große Datentransfere überflüssig und es lassen sich relativ
leicht Broadcasts erzielen.

Viel Spaß beim basteln!

Marcus

Autor: Michael (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
""Weiterhin kann ich immer nur von dem Master zu den Slaves Daten
uebertragen, aber nicht umgekehrt?

So ist das nicht gemeint. Der Master kann einen Slave auch auffordern,
Daten zu senden. Die Knechte dürfen aber nicht selbst damit anfangen.
Die RX-Eingänge der Slaves werden an TX-Ausgang vom Master
angeschlossen; die TX-Ausgänge der Slaves werden 'verodert'
(Diode+Widerstand) zum RX-Master geschaltet. Oder man nimmt RS485
Treiber mit entsprechender Aktivierung.

Meine Behauptung TWI und 50cm ist nicht der absolute Grenzwert. Auch
für TWI gibt es Treiberbausteine für lange Leitungen (z.B. P82B96).
Falls Du aber Deine Slaves mit Soft-UARTs betreiben willst, da würde
ich eher TWI über 2m riskieren oder alles mit einem Controller
erledigen. Das Uboot soll ja auch wieder auftauchen ?

Autor: Zoltan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich fasse mal zusammen:
USART mit einem Master und vielen Slaves. Verbunden über zwei Leitungen
mit Diode und Widerstand an den Tx- Ausgängen der Slaves.
Ablauf: Master sendet als erstes die Ziel-Adresse (mit 9. Bit). Alle
Slaves reagieren mit einem Interrupt, und entscheiden, ob die Nachricht
für sie bestimmt ist oder nicht. Wenn ja, dann empfängt der
betereffende Salve die Nutzdaten, und sendet anschließend seine Daten
an den Master (eventuell mit einer Zeiladresse, an die der Master die
Daten des ersten Slaves weiterleiten soll).

Das wäre eine erste Alternative, die wenn es so funktioniert, wie ich
mir das vorstelle , für meine Zwecke ausreichen würde.
Die zweite möglichkeit ist dann also das TWI, in dem ich mich noch
einarbeiten muss...

Gruß
Zoltan

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

Bewertung
0 lesenswert
nicht lesenswert
""Ich fasse mal zusammen:
Genau :-)

Ich habe mir 'mal den Spaß gemacht, mpcm-slave-Routinen zusammen zu
kopieren: nicht vollständig und ohne Gewähr. Ursprung vom Mega128, dann
auf Mega8 reduziert. Vielleicht hift es Dir.
Als Master nehme ich z.Zt. keine AVRs.

Autor: Frankl (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Zoltan ich finde Deine mehr µC Lösung für machbar, zumal dann die
einzelnen µC in ihrer Performance nicht ausgereizt sind. Auch hast du
mehrere Interupts zum Einlesen von Daten.
Ich würde ein Master mit mehrer Slaves wählen, mit SPI. Da brauchst du
keine Softwareemulation da ja schon im AVR eingebaut. Die µC mit
Pfostenstecker und endsprechenden abgeschirmten Kabel verbinden. Der
gleiche Pfostenstecker kann denn auch zum Programmieren der einzelnen
µC benutzt werden.

Autor: Zoltan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Michael "die TX-Ausgänge der Slaves werden 'verodert'
(Diode+Widerstand) zum RX-Master geschaltet."

Kannst Du bitte die Beschaltung genauer ausführen?


@Frankl
Danke für den Tipp. Ich möchte mir den SPI aber für andere Zwecke frei
halten, und leiber die speziell für die Komunikation vergesehenen
Feautures der AVR (wie USART, TWI) benutzten.

Gruß
Zoltan

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

Bewertung
0 lesenswert
nicht lesenswert
Hallo Zoltan,

viele Wege führen nach Rom. Gemeint hatte ich eine Schaltung mit
RS232-Pegeln, wie sie in Version 1 dargestellt ist. Abhängig von
Baudrate und Kabelkapazität kann jeder Slave auch einzeln z.B. an einem
PC betrieben werden; das ist der Vorteil. Der Nachteil ist, daß jeder
Slave-Treiber die übrigen Widerstände gegen V- überschreiben muß. Bei
vier Teilnehmern ergibt sich ein Lastwiderstand von ca. 1k5 (4k7/3).
Bei max. 10mA Treiberstrom erhält man einen Pegel von 15V bezogen auf
V- (<= -8V) und somit über +5V am RS232-Empfänger. Soweit, so gut.

Version 2 verzichtet auf die separaten Widerstände der Slaves und
verwendet einen einzigen Pulldown-Widerstand am Empfänger. Hiermit kann
eine größere Anzahl von Slaves betrieben werden.

Und bevor sich der massive Wieherstand der Datenblattanbeter formiert:
RS232 Empfänger haben ein typ. Schaltschwelle von 1,5V mit einer
Hysterese von ca. 0,5V. Somit kann man wie in Version 3
(Prinzipschaltung) gezeigt auch 0V als -Pegel verwenden und kommt ohne
neg. Versorgungsspannung aus.

Du hast die Wahl der Qual, o.ä. :-)

Autor: wolli (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ist so machbar, ich würde aber trotzdem RS485 nutzen. Mit den
differentiellen Signalen ist es erheblich störunanfälliger, es hat für
Master und Slaves eine einheitliche Beschaltung und ist einfacher
erweiterbar. Wer Master und Slave ist legt die Software fest, so dass
der Master auch im Betrieb wechseln kann (wenn man das benötigt).
Weiterhin sind RS485-Treiber schon mit 8 Pins zu haben.

Autor: Zoltan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Michael
Also erstens Danke für die Sachaltungen.
Meinst Du mit "RS232 Pegeln", dass ich die Ausgänge der µC mit einem
RS232 Treiber zuerst auf die +-12 V bringen muss, um Deine Schaltung
benutzen zu können?

Bei Reichelt kostet der MC1489P
(http://www.onsemi.com/pub/Collateral/MC1489-D.PDF) nämlich 0,25 EUR.
Ein RS485 Treiber (http://wwww.ges.cz/sheet/s/sn75176.pdf) ist aber mit
0,51 EUR auch nicht viel teurer. Daher würde ich den 485-Treiber-IC
bevorzugen. Bei dem habe ich dann aber das Problem, die Daten-Richtung
mit einem weiteren Port steuern zu müssen. Also wenn ich sowieso zuerst
die RS232 Pegel erzeugen müsste, würde ich doch gleich den RS485
benutzen.




Ich im Datenblatt des Atmega8 den Kapitel TWI überflogen. Wie es mir
scheint, ist der Unterschied zur USART, dass der TWI die Adressierung/
Datenaustausch mit mehreren Teilnehmer unterstützt (hat z.B. einen
extra Adressenregister: TWAR). Weiterhin benötigt er nur zwei Leitungen
und ist nur für "geringe" Entfernungen verwendbar.

Ist es nicht möglich die Entfernung zwischen den µC zu vergrößern,
indem ich z.B. einen RS485 Trieber an den TWI anschließe?


Gruß
Zoltan

Noch eine Seite zu RS485 aus dem Internet:
http://www.elektronik-projekt.de/view_articles_16.html

Autor: Michael (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Zoltan,

mein Beispiel bezog sich darauf, daß RS232-Pegel bereits vorhanden
sind; wie in Version 3 gezeigt, reicht aber auch ein Signal 0V -> +3V.
Als Empfänger tuts auch ein invertierender Transistor, womit dann die
Ruhestromaufnahme der Treiber und Empfänger 0mA beträgt.

Du kannst natürlich auch RS485-Signale nehmen, obwohl hierfür keine
Notwendigkeit bei mittlerer Baudrate und 2m Entfernung besteht. Das,
was Wolli vorschlägt, geht noch einen Schritt weiter. Er schlägt eine
halbduplex Verbindung mit Multimastern vor. Auch das kannst Du machen;
ist eine feine Sache, wenn es funktioniert.

Für TWI braucht man spezielle Treiber (s.o.).

Autor: Zoltan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ok, ich habe nun drei Möglicheiten:
-USART in Multi Master Mode + Transistorschaltung (Version 3)
-USART in Multi Master Mode + RS485 Neztwerk
-TWI mit Treiberbausteinen

Ich habe nur noch eine Frage zu dem I²C Trieber P82B96:
Welche Treiber könnte ich anstelle von dem noch benutzen (den es
eventuell auch bei Reichelt gibt) ?

Zur Info:
http://www.cpdee.ufmg.br/~diogenes/pse/Transp/Aula...
Dieser interessante Artikel vergleicht die verschiedenen BUS-Systeme.

Autor: Michael (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Man darf nicht erwarten, spezielle Bauteile bei 'normalen' Händlern zu
bekommen. TWI-Extender werden wohl erst dann in Mode kommen, wenn in
irgendeiner Zeitschrift entsprechende 'Projekte' veröffentlicht
werden.

Ohne Dich zu verwirren, es gäbe noch eine Alternative zu RS485:
CAN-Bustreiber. Z.B. den PCA82C250 ff. Der hat den Vorteil,
kollisionsfest und robust zu sein. Aber wo und wie teuer der angeboten
wird, keine Ahnung (das heißt doch: 2 -> 3€).
Da habe ich mir gerade noch einmal das Datenblatt angesehen und frage
mich nun, warum die Teile bei mir im Regal schlummern und ich die nicht
selber verwende: sehr schöne Teile!

Autor: Zoltan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bei Reichelt gibts den PCA82C250, (Juhu :-)) für 1.40 EUR.
Könnte ich den also anstelle des P82B96 als TWI-Treiber verwenden?

Autor: Michael (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nein.

Autor: Zoltan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sorry, ich habe Deine Antwort vorhin nicht gründlich gelesen. Der
PCA82C250 ist für den RS485.

Zum TWI:
Stimmt das, dass nur der µC einen Interrupt ausführt, der auf dem BUS
Adressiert wurde? Der AdressMatchUnit sorgt dafür, dass der
Interruptflag (TWINT) bei einem Slave nur dann gesetzt wird, wenn der
Master diesen Slave adressiert hat. Bei den restlichen (nicht
adressierten) Slaves wird das Programm nicht unterbrochen.
Ist das korrekt?

Gruß
Zoltan

Autor: wolli (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
CAN wird aber erst "Kollisionsfest", wenn ein CAN-Controller verwendet
wird. Also entweder einen CAN-Controller (SJA1000) und den o.g.
Bustreiber verwenden oder CAN in Software umsetzen (ist kompliziert und
braucht Rechenzeit).
Der CAN-Controller kostet aber erheblich mehr (ca. 5 Euro?) und nimmt
zusätzliche Fläche ein.
Also doch RS485?

Autor: Zoltan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn das oben stimmt, dass bei der TWI nur der Adressierten µC ein
Interrupt ausgeführt wird, dann ist der TWI mein klarer Favourit.

Autor: Michael (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Zoltan
TWI per Interrupt habe ich nie gemacht; kann Dir also nichts dazu
sagen.

@wolli
Mit kollisionsfest meine ich, daß ein Sender eine '1' und der andere
eine '0' ausgibt ohne die Ausgangstreiber gegenseitig
kurzzuschließen. RS422/RS485 Treiber haben push-pull Ausgänge, wenn
aktiviert; da gibt es Probleme - bei CAN nicht.

Autor: Zoltan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Michael
Gibt es ähnliche Trieber, wie den P82B96, die man auch als
normalsterblicher bekommen kann?

Autor: Michael (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Zoltan,

da kann ich Dir nicht weiterhelfen. Da solltest Du Suchmaschinen
bemühen. Ich würde das Problem mit USART angehen; Lösungsansätze sind
Dir nun bekannt. Aber mach, was DU für richtig hälst.

Autor: Zoltan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ok, jetzt weiß ich, wo ich anfangen muss.

Danke und Gruß
Zoltan

Autor: harry (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
na klasse, einfacher geht's kaum noch. oder doch? auf jeden fall:
1. den ganzen treiberkruscht weglassen, die procs hängen doch keinen
kilometer auseinander. 5v-pegel (oder auch 3v reichen doch allemal)
was die störsicherheit anbelangt, es darf ja schon für die paar
millisekunden ein strom von 5-10mA fliessen, das ist betriebssicher.
die baudrate runter auf z.b. 2400 baud, 10nf kondensatoren gegen gnd,
damit machst du die signalflanken etwas weicher, aber sehr unanfällig
gegen störungen.
2. das protokoll kann doch so aussehen: ein proc. macht den master, die
anderen die slaves. master ruft den 1. slave, der antwortet, ... master
ruft den n. slave, der antwortet, fertig. sendepause, irgendwann
geht's wieder los.
schon sind alle infos der slaves im master, der wertet aus und
agiert...
ist alles vielleicht nicht suppi-elegant, hat keine technischen
finessen, geht aber ratzfatz umzusetzen ohne gross zusätzliche bauteile
und protokoll. kommt eher auf ein projekt für einfache menschen, die's
einfach mögen, raus.

nur als anregung zu verstehen, bitte. ich weiss, dass die technik auch
überflieger zu bieten hat, aber braucht's die dazu????

gruss, harry

Autor: Zoltan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi harry,

1.
Ich will den TWI als erstes ohne Treiber ausprobieren. Die Recherche
nach einem I2C-Trieber soll mir eine Hintertür offenlassen, falls die
direkte Verbindung doch nicht störsicher genug wäre.
Die 2400 Baudrate ist leider viel zu wenig, ich habs bereits
Ausprobiert. Aber danke für den Tipp.

2.
"das protokoll kann doch so aussehen:..."
Ja, genauso habe ichs mir auch gedacht (siehe 1. Bild im Thread).

Gruß
Zoltan

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

Bewertung
0 lesenswert
nicht lesenswert
Ich habe eine TWI-Verbindung zwischen zwei Atmega8 aufgebaut (software
Master, hardware Slave).  Das Programm für den Master habe ich von
Peter Fleury-s Seite, und den Kode für der Slave, hier aus dem Forum
zusammen geschustert.

Der Master sendet jetzt einen Wert, den er über den USART empfangen
hat, über den TWI an den Slave. Nach einem zweiten Aufruf sender der
Slave den Wert zurück, aber leider immer um eine Stelle nach links
verschoben (z.B. senden 3, zurück 6). Wenn eine Zahl, die den MSB
enthält (z.B. 64), vom Master gesendet wird, dann hängt sich alles
auf.

Wenn ich in den Salve eine festen Rückgabe-Wert einprogrammiere, dann
empfängt der Master diesen jedoch korrekt. Daraus schließe ich, dass
bereits der Master die Daten um eine Stelle verschoben/geschiftet
sendet, oder der Slave diese falsch einliest. Ich komme aber einfach
nicht dahinter warum. ???

(
Ich habe in der Peters Files die Taktfrequenz von 8 MHz geändert, und
beim Senden die Adresse um eine Stelle nach rechts geschiftet, denn mir
ist dieser Befehl hier nicht ganz klar:

ret = i2c_start(Slave1+I2C_WRITE);

es sollte doch heißen(?):
ret = i2c_start((Slave1<<1)+I2C_WRITE);

Dementsprechend ist in dem Slave Programm:

TWAR=0;
TWAR|= (OWN_ADR<<1);   // Reciever adress

...da die LSB doch für den "general call" zuständig ist.
Die Adressierung oben überschreibt aber den LSB, anstelle die
Ziel-Adresse "rechts davon", in den restlichen 7 bit zu speichern.
)

Habt Ihr vielleicht eine Idee, was ich ich falsch gemacht habe?

Gruß
Zoltan

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

Bewertung
0 lesenswert
nicht lesenswert
Da ich diesen Thread "ordentlich" abschließen möchte, hänge ich moch
meine nun funktionierende Dateien an. Enthalten ist ein software Master
(größten teils von
http://homepage.sunrise.ch/mysunrise/pfleury/avr-s...)
und zwei hardware Slaves. "Alles" in C.
Der Master sendet jeweils einen Byte an jeden Slave und diese senden
den Wert zurück zum Master. Die serielle Schnittstelle dient zur
Steuerung und Kontrolle der Daten dient zwischen µC und PC.

Danke nochmal für die Hilfe
Gruß
Zoltan

Autor: ulrich strobel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
was soll der stress, nim doch einfach für den inkrementalgeber einen
seperaten kontroller und mache ansonsten alles mit dem anderen, du
kannst natürlich für mit dem inkrementalgeberµC auch noch A/D Wandler
funktionen übernehmen oder ausgänge Schalten. Die beiden kannst du ohne
weiteres dann mittels UART oder MOSI vernetzen, weiterhin kannst du
auch mittels MOSI und dem passendens Schieberegister 74XX164 oder 4097
(schätzung)  seperate O Karten in dein Uboot legen, dazu würde ich dir
aber auf alle Fälle geschirmte Kabel empfehlen (Netzwerkkabel).
Mit dem 74XX165 könnte man dan noch seperate I Karten realisieren.

MFG

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.