Hallo, für eine Wohnraumbeleuchtung plane ich folgendes : Auf einem Atmega32/644 liegen mehrere Makros, die Lichtszenarien beinhalten. Über eine Uart Verbindung sind 3-4 Attiny2313 (4PWM) angeschlossen. Atmega sendet : Attiny1 , LED Kette langsam dimmen Attiny2 , LED Sternenhimmel langsames durchfade usw ..... Auf den jeweilgen Attinys findet dann die PWM Umsetzung der Makros statt. Wie adressiere ich die einzelnen Attinys ? Läuft die Steurung über ein Kabel / Verbindung ? Kann mir jemand ein paar Infos oder Links zu diesem Thema liefern ? Danke
>Wie adressiere ich die einzelnen Attinys ? Indem du ihnen Nummern verpasst. >Läuft die Steurung über ein Kabel / Verbindung ? Nö, GND muss auch noch sein. Also zwei Kabel.
@holger Kannst du mir das bitte ein wenig genauer erklären ?
>Kannst du mir das bitte ein wenig genauer erklären ?
ATTiny1 Hausnummer 1
ATTiny2 Hausnummer 2
Dann Master:
Sende Hausnummer1+ Befehl an ATTiny1
Sende Hausnummer2+ Befehl an ATTiny2
>UART im Multiprozessormode.
Das war jetzt ja wohl ein Griff ins Klo ;)
>ATTiny1 Hausnummer 1 >ATTiny2 Hausnummer 2 >Dann Master: >Sende Hausnummer1+ Befehl an ATTiny1 >Sende Hausnummer2+ Befehl an ATTiny2 So habe ich mir das auch ähnlich gedacht. Wie adressiere ich die Attiny denn ?
Hi
>Das war jetzt ja wohl ein Griff ins Klo ;)
Was ist daran gross anders, als bei deiner Variante? Ausser das Bit8 als
Adresskennzeichen benutzt wird. Und die Slaves werden wesentlich weniger
belastet.
MfG Spess
>>Das war jetzt ja wohl ein Griff ins Klo ;) >Was ist daran gross anders, als bei deiner Variante? Ausser das Bit8 als >Adresskennzeichen benutzt wird. Und die Slaves werden wesentlich weniger >belastet. Nichts, außer das es für den Probanden zu kompliziert ist. Siehe seine letzte Antwort bei der ich gar bitterlich weinen muss ;)
Der "Proband" möchte ja auch mal klüger werden, darum fragt er hier ja auch
>Der "Proband" möchte ja auch mal klüger werden, darum fragt er hier ja >auch SendUart(Hausnummer1) SendUart(Befehl) SendUart(Hausnummer2) SendUart(Befehl) Klingelt jetzt was?
Hi >Nichts, außer das es für den Probanden zu kompliziert ist. >Siehe seine letzte Antwort bei der ich gar bitterlich weinen muss ;) Wenn er aber seinen Slaves auch noch beibringen muss, nicht auf falsche Daten zu reagieren, werden seine Fragen dich wahrscheinlich noch wesentlich weinerlicher stimmen. @ Tom (Gast) Nichts für ungut. Aber wenn du es machen willst, dann mach es richtig. MfG Spess
@spess53 ich höre dir wissbegierig zu :-) Es soll schon funktionieren
>@spess53 >ich höre dir wissbegierig zu :-) Es soll schon funktionieren Mal sehen wie spess53 da wieder raus kommt ;)
Hi Gut eine Kurzeinführung: Normalerweise werden 8 Bit zur Übertragung verwendet. Multi-processor Communication Mode (MPCM) werden 9 bit verwendet. das 9. Bit (Bit8) dient zu Kennzeichnung einer Adresse. Zusätzlich gibt es in UCSRA nnoch das MPCM-Bit. Wenn dieses Bit gesetzt ist wird ein RXC-Interrupt nur ausgelöst, wenn Bit 8 gesetzt ist. Bei der Initialisierung setzen alle Slaves ( deine ATTiny) dieses Bit. Wenn der Master (dein ATMega) einen Slave Adressieren will, setzt er Bit8 auf 1 und lädt die unteren 8 Bit (UDR) mit der Adresse. Bei allen Slaves wird beim Empfang ein RXC-Interrupt ausgelöst. Jetzt überprüfen alle Slaves, ob das die eigene Adresse (in UDR) ist. Wenn nicht kann weiter geschlafen werden. Der Slave mit der übereinstimmenden Adresse löscht jetzt das MPCM-Bit. Damit wird auch bei Bit8=0 ein RXC-Interrupt ausgelöst. Der Master sendet die Daten mit gelöschtem Bit 8. Damit empfängt nur der zuvor adressierte Slave die Daten. Die anderen werden davon überhaupt nicht belästigt. Wenn der Slave alle Daten empfangen hat, setzt er sein MPCM-Bit wieder auf 1 und wird dadurch wieder nur auf eine neue Adress empfänglich. Danach kann er in Ruhe die empfangenen Daten verdauen. Ich hoffe das war einigemassen verständlich. Ist auch im Datenblatt nachzulesen. MfG Spess
Soweit erste einmal Danke für die Kurzeinweisung. Ist schon was anderes, als ein paar LED zu dimmen :-) Damit ich mich nun weiter schlau machen kann, ist mein Stichwort "RS485" ?! Zumindest wurde dieses Protokoll genannt, als ich nach "Multiprozessormode" gesucht habe. Und da ich keine bidirektionale Kommunikation brauchem sonder lediglich willige "Befehlsempfänger", reichen 2 Leitungen aus ?!
Nicht böse sein spess53. Aber das ist doch für Tom noch viel zu
kompliziert.
Lass ihn doch einfach seinen Master UART mit allen Slaves verbinden.
Der Master UART brüllt dann einfach raus: Befehl an Tiny mit der Nummer
25, mach dieses.
Der Tiny mit der Nummer25 reagiert auf den Befehl, alle anderen
ignorieren ihn ganz einfach.
Das ist so, wie wenn du 20 Schüler in einem Raum hast. Ehe alles
losgeht, verpasst du jedem eine Nummer.
Und dann brüllst du einfach in den Raum hinein: 23, Fenster aufmachen.
Hans (der vorher die Nummer 23 zugeordnet bekommen hat) macht das dann,
während Fritz (mit der Nummer 17) den Befehl ignoriert.
Du denkst dir ein Schema aus, welches es dir gestattet eindeutig
zwischen Adresse und Befehl zu unterscheiden. Zb sind alle Befehle nru
Nummer zwischen 0 und 127 und alle Adressen sind Zahlen zwischen 128 und
255. Wenn ein Tiny ein Byte empfängt braucht er nur nachsehen:
Ist das Byte größer 127?
+- Wenn ja
| Stimmt die Adresse mit meiner eigenen überein?
| +- Wenn ja
| | Schalte mich scharf, das nächste Byte ist mein Befehlsbyte
| +- Wenn nein
| nichts tun
|
+- Wenn nein
Bin ich auf einen Befehl scharfgeschaltet?
+- Wenn ja
| Befehl ausführen
+- Wenn nein
Nichts tun
Scharfschaltung rückgängig machen
Du kannst dir ja auch mal überlegen, wie sich das Auswerteschema
verändern würde, wenn man ganz einfach Befehl und Adresse umdrehen
würde. D.h. zuerst wird der Befehl übertragen und dann an wen der Befehl
gerichtet ist. Um beim Beispiel zu bleiben:
"Fenster auf" - alle Schüler spitzen die Ohren
23 - Nur Hans geht, alle anderen spielen weiter Karten
Ist das Byte kleiner 127?
+- Wenn ja
| Befehl für eine mögliche Ausführung speichern
+- Wenn nein
Stimmt die Adresse mit meiner eigenen überein?
+- Wenn ja
Befehl ausführen
Das ganze ist wirklich keine Hexerei, geh einfach davon aus, dass du
eine Menge von Menschen hast, die alle strohdumm sind und die du
fernsteuern musst, indem du Zahlen in die Menschenmenge hineinbrüllst.
Wie würdest du das machen?
Der von spess53 angesprochene Multiprozessormode ist nur eine
Möglichkeit, wie man Adressierung and Daten voneinander trennen kann und
wie die Slaves nur dann belästigt werden, wenn es notwendig ist. Bei dir
ist aber die Last an den Slaves nicht besonders hoch, so dass du nicht
darauf angewiesen bist, auch noch das letzte bischen Rechenzeit
herauszuquetschen. Ehe du Sondermodi in der UART Übertragung benutzt,
solltest du meiner Meinung nach erst mal mit den Standardmodi und einer
Standardübertragung klarkommen.
Fang erst mal an den Master mit einem Slave reden zu lassen und dem
Befehle zu schicken. Dann hast du schon mal ein wesentlich besseres
Rüstzeug um mehrere Slaves an die UART zu hängen.
Wieso eigentlich nicht I²C nehmen? Das ist doch extra für solche zwecke gedacht!
Timmo H. schrieb: > Wieso eigentlich nicht I²C nehmen? Das ist doch extra für solche zwecke > gedacht! Leitungslänge.
>Wieso eigentlich nicht I²C nehmen?
weil uart schon in hardware implementiert ist ... und für diese einfache
aufgabe vollkommen ausreicht.
karl heinz hat das schon super beschrieben, dem kann ich nichts
hinzufügen.
jeder slave lauscht auf dem TX des masters und entscheidet anhand von
dem was er hört, ob er gerade angesprochen ist.
nicht sehr sicher, aber ob eine lampe mal nicht angeht interessiert den
master ja herzlich wenig.
I2C wäre auch super geeignet, bedeutet auch nur einen geringfügigen
mehraufwand.
die leitungslänge sollte man mal noch betrachten ....
Hi >Nicht böse sein spess53. Aber das ist doch für Tom noch viel zu >kompliziert. Der zusätzlich Aufwand beschränkt sich auf die Manipulation eines Bits beim Master und eines Bits beim Slave. Wenner das nicht packt, hat sowiso das falsche Hobby. >Und da ich keine bidirektionale Kommunikation brauchem sonder lediglich >willige "Befehlsempfänger", reichen 2 Leitungen aus ?! Masse macht sich auch nicht schlecht. Also 3. >Wieso eigentlich nicht I²C nehmen? Das ist doch extra für solche zwecke >gedacht! Wenn du das richtig, also mit der implementierung aller möglicher Zustände machst, ist es nicht ganz ohne. MfG Spess
wow, danke für die rege Teilnahme. Die Leitungslänge liegtbei ca. 20 cm. @Karl heinz Buchegger Danke, super Erklärung. Ich denke, dass dies wohl doch erst einmal der richtige Weg für mich ist. Hört sich immer ncoh schwierig genug an. Bei diesem System "hört" der slave also ständig, ob der master etwas in den Raum brüllt. Dies "blockiert" also seine eigentliche Arbeit --> Dimmen und schalten von Licht ? Da diese Szenarien nicht ständig wechseln, wäre diese "Ablenkung" aber nicht tragisch ?! @spess53 Naja, ich denke einmal , das auch du nicht als sprechender Mensch auf die Welt gekommen bist, aber es dennoch versucht hast, sprechen zu lernen. Ebenso versuche ich dies im Bereich der mc zu tun. Von einem "falschen" Hobby kann also meiner Meinung nach nicht gesprochen werden. Dennocoh danke für deine Hilfe
Tom schrieb: > Raum brüllt. Dies "blockiert" also seine eigentliche Arbeit --> Dimmen > und schalten von Licht ? Kommt drauf an. Bei Dimmen hat der µC ständig was zu tun. Er muss ja die PWM bedienen. Aber das kann der auch genausogut in Hardware machen. Bei Schalten muss der µC ja nicht ständig was tun. Er schaltet das Licht ein oder aus und legt sich dann wieder schlafen. Wenn das Licht erst mal brennt oder aus ist, gibts ja nichts mehr zu tun. Du musst ja auch nicht dauernd beim Lichtschalter stehen bleiben :-) > lernen. Ebenso versuche ich dies im Bereich der mc zu tun. Von einem > "falschen" Hobby kann also meiner Meinung nach nicht gesprochen werden. Na ja. Du denkst im Moment noch viel zu kompliziert und machst dir über Details Sorgen, die in Wirklichkeit keine sind. Dafür lässt du es an konstruktiver Phantasie mangeln. Das merkt man schon an deinen Fragen. Genauso wie man aus deinen Fragen heraushören könnte, dass dir noch 3 oder 4 Vorstufen zu deiner Problemlösung fehlen.
Hi >Ebenso versuche ich dies im Bereich der mc zu tun. Von einem >"falschen" Hobby kann also meiner Meinung nach nicht gesprochen werden. >Dennocoh danke für deine Hilfe Das hatte sich lediglich auf das setzen eines Bits bezogen. >Die Leitungslänge liegtbei ca. 20 cm. Wenn du keine total elektrosmogverseuchte Umgebung hast, brauchst du bei der Entfernung kein RS485. Da reicht Signal und Masse. MfG Spess
>Dies "blockiert" also seine eigentliche Arbeit --> Dimmen
und schalten von Licht ? Da diese Szenarien nicht ständig wechseln, wäre
diese "Ablenkung" aber nicht tragisch ?!
wenn du die dimmung über eine hardware (timer) pwm realisierst, hast du
die komplette rechenzeit des µC brachliegen ... selbst wenn du 100 mal
pro sekunde dein beleuchtungsszenario änderst, wird sich der µC bei
20MHz noch langweilen.
und sogar bei PWM in software brauchst ja auch max 200Hz für die
PWM-frequenz ... d.h. der wird mehr warten als sich mit dem ändern der
ausgänge beschäftigen.
Ok. Nochmals vielen Dank. Ich werde euch hoffentlich im Laufe meines Projektes ein paar Fortschritte zeigen können. Bis dahin
Hi! Ich hab mal mehrere UARTs über Multiplexer und Demultiplexer angesprochen. Ist zwar für Deine zwei Slaves ein höherer Schaltungsaufwand, aber dadurch vereinfacht sich die Software der Slaves und man hat kein Problem damit die ganze Geschichte zu erweitern. bye Data
>Ich hab mal mehrere UARTs über Multiplexer und Demultiplexer >angesprochen. Ist zwar für Deine zwei Slaves ein höherer >Schaltungsaufwand, aber dadurch vereinfacht sich die Software der Slaves >und man hat kein Problem damit die ganze Geschichte zu erweitern. Was ist einfacher anzupassen? Hardware oder Software? Wenn man sich ein sinnvolles Protokoll ausdenkt, ist das auf jeden Fall einfacher (zu erweitern) als irgendwelche Hardware.
Ich verstehe immernoch nicht warum kein I²C. Das ist doch viel einfacher, und der AVR hats in Hardware drin. Man braucht nur noch die Adressen für jeden Empfänger festlegen und gut is.
Hi
>Man braucht nur noch die Adressen für jeden Empfänger festlegen und gut is.
Hast du dir das Kapitel im Datenblatt mal richtig durchgelesen?
MfG Spess
Hi Nachtrag @Timmo: Der ATTiny2313 den Tom verwenden will hat z.B. kein Hardware-I2C. MfG Spess
>Ich verstehe immernoch nicht warum kein I²C. Das ist doch viel >einfacher, und der AVR hats in Hardware drin. Man braucht nur noch die >Adressen für jeden Empfänger festlegen und gut is. I²C erwartet ein Handshake. USART nicht. Wenn der Slave auf die I²C-Nachricht nicht antwortet, hängt der Master u.U. irgendwo im Programm fest. Wenn der Slave keine Nachricht per USART empfängt, ist das dem Master sehr egal, weil er eh keine Antwort erwartet.
spess53 schrieb: > Hast du dir das Kapitel im Datenblatt mal richtig durchgelesen? Ja, und auch schon mehrfach benutzt. >Nachtrag @Timmo: Der ATTiny2313 den Tom verwenden will hat z.B. kein >Hardware-I2C. Der 2313 hat USI und damit geht auch Two-Wire Mode, kann also auch als TWI verwendet werden. Dafür hat Atmel sogar eine Application Note: http://www.atmel.com/dyn/resources/prod_documents/doc2560.pdf Gut ist programmiertechnisch vielleicht etwas aufwendiger als UART, aber der Quellcode ist ja schon fertig.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.