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
Angehängte Dateien:
-
AVRVernetzten.gif
21 KB
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
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.
Hhm, das klingt alles nach relativ langsamen Prozessen. Wo genau siehst Du hier Schwierigkeiten das auf einem Controller zu realisieren? Gruß, Frank
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
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
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
@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.
@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).
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
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
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
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.
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
Wenn Du sowieso auf Polling-Basis kommunizieren willst, ist das USART optimal. Mit RS485-Treibern ist die Reichweite auch auf jeden Fall ausreichend.
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
""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 ?
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
""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.
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.
@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
Angehängte Dateien:
-
mpcm_slv.png
5,3 KB
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.ä. :-)
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.
@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
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.).
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/Aula17-serialbus.pdf Dieser interessante Artikel vergleicht die verschiedenen BUS-Systeme.
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!
Bei Reichelt gibts den PCA82C250, (Juhu :-)) für 1.40 EUR. Könnte ich den also anstelle des P82B96 als TWI-Treiber verwenden?
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
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?
Wenn das oben stimmt, dass bei der TWI nur der Adressierten µC ein Interrupt ausgeführt wird, dann ist der TWI mein klarer Favourit.
@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.
@Michael Gibt es ähnliche Trieber, wie den P82B96, die man auch als normalsterblicher bekommen kann?
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.
Ok, jetzt weiß ich, wo ich anfangen muss. Danke und Gruß Zoltan
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
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
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
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-software.html#libs) 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
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
Thread beobachten
Seitenaufteilung abschalten
Bitte 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.