Guten Tag, ich stehe vor folgendem Problem: Ich habe viele (ca 200, werden aber noch mehr, maximal 700) ATTiny13A (mit 9.6MHz), an denen RGB LEDs angeschlossen sind und per Software PWM gedimmt werden. Also sind an jedem AVR noch 2 Pins frei (3x LED, VCC, GND, RESET). Diese ganzen AVRs muss ich nun miteinander vernetzen, damit sie über ein Protokoll die RGB Daten empfangen können. Das sind 40Bit Nutzdaten pro AVR (16bit Adresse, 8bit rot, 8bit grün, 8bit blau). Diese Daten sollen ca 30mal pro Sekunde aktualisiert werden. Also müssen pro Sekunde maximal 40 Bit*700*30 = 840 000 Bit = 105 000 Byte übertragen werden... Die AVRs haben keine interne Hardware Schnittstelle... Mit welchem Protokoll/Interface würdet ihr das lösen? Auf dem AVR sind noch ca 400Byte Speicher frei... Viele Grüße ;)
Willst du das nicht lieber über entsprechende Treiber lösen? zB WS2801? Die kann man kaskadieren und es entfällt das Programmieren von 200-700 µC.
Clk und Data mit RS422 (EIA-422) Treibern und jeder 10. Empfänger ist ein Repeater. Jeder tiny braucht 2 RS422 Empfänger. http://de.wikipedia.org/wiki/EIA-422
Hallo, ich würde das ganze mit Software TWI lösen, vielmehr bleibt ja nicht ... Aber warum 16Bit Adresse ? Wenn du max. 700 µCs adressieren willst, dann reichen doch 10Bit zur Adressierung aus. nikolaus schrieb: > Diese Daten sollen ca 30mal pro Sekunde aktualisiert werden. Möchtest du Animationen darstellen ? nikolaus schrieb: > Auf dem AVR sind noch ca 400Byte Speicher frei... guter Grund, um mal wieder den Assembler auszupacken ;) Gruss Uwe
Lord Ziu schrieb: > Willst du das nicht lieber über entsprechende Treiber lösen? zB WS2801? > Die kann man kaskadieren und es entfällt das Programmieren von 200-700 > µC. Aber so kann ich doch keine einzelnen LED's steuern, oder hab ich da was im Datenblatt übersehen? Uwe schrieb: > Clk und Data mit RS422 (EIA-422) Treibern und jeder 10. Empfänger ist > ein Repeater. Jeder tiny braucht 2 RS422 Empfänger. > http://de.wikipedia.org/wiki/EIA-422 Einen extra Treiber wollte ich vermeiden, aber das währe wohl eine einfache und sichere Lösung... Uwe N. schrieb: > ich würde das ganze mit Software TWI lösen, vielmehr bleibt ja nicht ... > Aber warum 16Bit Adresse ? Wenn du max. 700 µCs adressieren willst, dann > reichen doch 10Bit zur Adressierung aus. Ja, die Reichen auch aus, ich habe mit 16 Bit gerechnet um auch einen "Puffer" zu haben, eigentlich reichen 10 Bit locker aus. >> Diese Daten sollen ca 30mal pro Sekunde aktualisiert werden. > Möchtest du Animationen darstellen ? Ja, mehr oder weniger ;) die LED's werden aber nicht in einer Matrix angeordnet > guter Grund, um mal wieder den Assembler auszupacken ;) Das habe ich auch vermutet :D Ich überlege ob ein Software SPI nicht auch eine schlechte Idee wäre... einfach CLK an den INT0 Pin anschließen und bei jedem Interrupt dann den anderen Pin auslesen... Und damit es gut funktioniert die Leitungen mit einem MOSFET Treiber ansteuern... Und natürlich alle paar µC's einen Repeater... Nur wenn mal ein AVR ein Bit verschluckt spinnt alles total... Was haltet ihr davon?
nikolaus schrieb: > Was haltet ihr davon? Ungünstig wenn du nur 2 Pins frei hast: du brauchst entweder viele, viele CSs Leitungen oder wenigstens 3 freie Pins: CLK, DIN und DOUT zum durchschieben der Daten an den nächsten µC.
Uwe N. schrieb: > Ungünstig wenn du nur 2 Pins frei hast: du brauchst entweder viele, > viele CSs Leitungen oder wenigstens 3 freie Pins: CLK, DIN und DOUT zum > durchschieben der Daten an den nächsten µC. Jeder µC hat doch eine eigene Adresse, also kann ich alle CLK und DATA Leitungen verbinden (also nicht alle, dann wäre die Leitungskapazität zu hoch, aber bestimmt 20 oder so)
nikolaus schrieb: > Ja, die Reichen auch aus, ich habe mit 16 Bit gerechnet um auch einen > "Puffer" zu haben, eigentlich reichen 10 Bit locker aus. Einen Buffer von immerhin 324 Möglichkeiten hast du auch bei 10Bit ... Gruss Uwe
> Einen Buffer von immerhin 324 Möglichkeiten hast du auch bei 10Bit ...
Ich meinte bei der Übertragungsgeschwindigkeit ;)
nikolaus schrieb: > Jeder µC hat doch eine eigene Adresse, ... SPI benutzt keine direkte Adressierung wie TWI, wenn du eine Daisy Chain Konfiguration nutzt (dann würden 3 Pins reichen), dann muss du, wenn du z.B. den 10 µC in der Kette ansprechen willst, eben 11 x (xBit) senden, bis der Datenstrom in dem gewünschten µC eingetaktet ist. Deshalb würde ich lieber TWI nutzen, da kann man auch mal einzelne µCs ansprechen. EDIT: Dinge wie Repeater lass ich jetzt mal aussen vor.
Uwe N. schrieb: > SPI benutzt keine direkte Adressierung wie TWI, wenn du eine Daisy Chain > Konfiguration nutzt (dann würden 3 Pins reichen), dann muss du, wenn du > z.B. den 10 µC in der Kette ansprechen willst, eben 11 x (xBit) senden, > bis der Datenstrom in dem gewünschten µC eingetaktet ist. > > Deshalb würde ich lieber TWI nutzen, da kann man auch mal einzelne µCs > ansprechen. > > EDIT: Dinge wie Repeater lass ich jetzt mal aussen vor. Der µC hat ja kein SPI, deswegen hätte ich das auch in Software realisieren müssen, und dann kann ich so Sachen wie eine Adresse ja einbauen ;)
Uwe N. schrieb: > Deshalb würde ich lieber TWI nutzen, da kann man auch mal einzelne µCs > ansprechen. Hallo, RS485 wäre doch hier sicherlich auch angebracht oder? Ich mein mit gewissen Umsetzerbausteinen ist das auch wirklich Bus tauglich. Hab sowas in der Art auch schon einmal gemacht. Da würde die Übertragungsrate auch sicherlich nicht knapp werden. Aber hier ist noch kein Wort über die Kabellänge gesprochen worden. Je nach dem fällt hier dann IIC sowiso weg. Dennis
Dennis X. schrieb: > RS485 wäre doch hier sicherlich auch angebracht oder? Ja sicher, es muss etwas "langstreckentaugliches" sein, der TO möchte i.M. aber reine Protokoll-Fragen klären :)
Ich würde ein abgeändertes SPI-Protokoll empfehlen, um das soft-PWM möglichst wenig zu verfälschen. Z.B: 1. Data-High -> alle Attinys müssen innerhalb z.B 30 Takten in einer nop-Sequenz sein. 2. Data-Low -> alle Attinys springen per Interrupt in die Empfangroutine, die Zeit, die sie brauchen ist konstant, da sie vorher alle nur nop ausgeführt haben. 3. Die Daten kommen mit 4.8Mbit/s, nach den ersten 16bit ist eine Pause von 3 Takten, die nicht addressierten Avrs, beenden den Empfang 4. Der addressierte Attiny empfängt die Daten. Das ist asynchron und dafür reicht eine Leitung. 4.8Mbit Empfang kann man so erreichen:
1 | sbic PORTx, y |
2 | ori reg, 0 |
3 | ... |
4 | sbic PORTx, y |
5 | ori reg, 7 |
Wie kommt man eigentlich auf die Idee 700 Attinys zu verbinden?
nikolaus schrieb: > Lord Ziu schrieb: >> Willst du das nicht lieber über entsprechende Treiber lösen? zB WS2801? >> Die kann man kaskadieren und es entfällt das Programmieren von 200-700 >> µC. > Aber so kann ich doch keine einzelnen LED's steuern, oder hab ich da was > im Datenblatt übersehen? Na klar kannst du. Ein WS2801 steuert genau eine RGB-LED. 3 Anschlüsse vom WS2801 gehen auf R,G,B von der LED. Den WS2801 steuerst du über 2 Leitungen an. Du kannst für jeden WS2801 z.B. angeben, welchen PWM-Wert Anschluß1 (R), Anschluß2 (G), Anschluß3 (B) haben soll. Somit kannst du mit einem WS2801, einer RGB-LED und 3 Rs alle Farben darstellen die gehen. Und die KSQs sind auch schon auf dem Chip. Und du kannst die Dinger hintereinanderschalten. Wenn du zB 10 Stück kaskadierst, dann schickst du über deine (immer noch nur) 2 Leitungen vom µC halt nicht nur einen Steuerbefehl, sondern 10 Befehle, je einen pro LED. Bevor du versuchst 700 µC aufzubauen, womöglich noch mit serieller Verbindung und dem ganzen Aufwand der sich aus der Adressierung und sonst was ergibt, würde ich diese Lösung erstmal genauer unter die Lupe nehmen. Ganz zu schweigen davon, dass du für ~ 0,50€ pro Chip sicher billiger hinkommst, als mit der 700-Controller-Lösung.
Samuel K. schrieb: > 1. Data-High -> alle Attinys müssen innerhalb z.B 30 Takten in einer > nop-Sequenz sein. Wie meinst du das genau? Es kann ja sein, dass gerade wenn die Übertragung losgeht ein ATTiny in der ISR der PWM ist...
Das funktioniert nur wenn in der ISR sofort per sei die Interrupts freigegeben werden. In C muss man das mit __attribute__(naked) machen.
1 | INT0_vect: |
2 | sbic PORTx, y |
3 | rjmp nop_seq |
4 | |
5 | sbic PORTx, 0 |
6 | ori reg, 0 |
7 | ... |
8 | |
9 | ;SREG wiederhestellen |
10 | pop x ;nicht in die pop_seq zurückspringen |
11 | pop x |
12 | ;oder (auf Attiny13 schneller) |
13 | ;in x, SPL |
14 | ;subi x, -2 |
15 | ;out SPL, x |
16 | reti |
17 | |
18 | nop_seq: |
19 | ;SREG für später sichern |
20 | nop |
21 | nop |
22 | nop |
23 | nop |
24 | ... |
25 | Nach maximal 30-8 Takten wird zurueck in INT0_vect gesprungen |
26 | dann werden die Daten eingelesen |
Die Übertragung dauert vielleicht 15µs, wenn das zuviel ist musst du die Attinys wohl synchronisieren.
Hallo zusammen, was spricht eigentlich gegen rs232? Man muss dann einen attiny25 verwenden. Das ist aber in jedem Fall sinnvoll, weil es der Nachfolger des attiny13 mit mehr Speicher ist. Dazu 250kHz PWM und noch einiges anderes mehr zum gleichen Preis. RS232 läuft dann in Hardware ab. Nur wenn ein byte fertig ist muss es gelesen werden. Das kann man in einer state machine erledigen.
rs232??? da muss doch an jeden μC die entsprechende hardware oder denk ich gerade schief? aber ein projekt mit 700 μC möchte ich auch nicht finanzieren... vielleicht mal bisschen genauer um was es geht.. dennis
Dennis X. schrieb: > rs232??? da muss doch an jeden μC die entsprechende hardware wozu? Solange nur 1 Tiny mit einem anderen Tiny spricht ist es doch völlig Wurscht ob das auf RS232 +-12 Volt Pegeln oder auf 5V-TTL Pegeln passiert.
Gegen wohl alle Protokolle spricht die Aufwändigkeit. Sobald der µC empfängt, ist das SoftPWM blockiert. Daher scheidet SPI, UART, TWI von vornerein aus. Tiny25 ist deutlich teurer als Tiny13
Tiny13 für solch eine Anwendung verdient mein Respekt! Die Programmierung ist schon sportlich. Allerdings 700 Controller programmieren ist bestimmt kein vergnügen. Hoffentlich gibts da nie ein Firmwareupdate. Ich habe schon mal 120 RGB gebraucht und die dann mit WS2801 betrieben. Das war zwar unsportlicher, hat aber dafür sofort funktioniert ;-) In den Stückzahlen bekommst Du den WS2801 schon für 40 Cent. http://shop.soda-light.de/product_info.php?info=p14_ws2801-rgb-led-treiber.html&XTCsid=hkbjipm1r5a3t3cm5bhnijtkl1 Bei 700 Stück ist vielleicht noch mehr drin. Gruß kokisan
Hallo, ich habe nun nochmal etwas genauer darüber nachgedacht... Ich werde die LEDs in Gruppen von maximal 256 Geräten unterteilen. Dann muss ich nur noch 32 Bit (8 Bit Adresse, und jeweils 8 Bit Farbdaten) übertragen. Also habe ich für jedes Paket 130µs Zeit. (1s/(30 Bilder/s)/256 = 130) in den 130µs müssen dann 32 Bit übertragen werden, das macht also 130µs/32 = 4µs bzw ca 250kHz. Der AVR läuft mit 9.6MHz, d.h. pro Takt braucht er ca 0.1µs, also hätte ich ca. alle 40 Takte einen Interrupt. Denkt ihr das ist in Assembler ein lösbares Problem oder wird das zu knapp? Danke schonmal für eure Hilfe ;)
40 Takte geht gut, bedenke aber dass dein softpwm unterbrochen werden muss, sonst funktionmiert es nicht mehr. Sag bitte nicht, dass das eine Led-Matrix wird...
Samuel K. schrieb: > Sag bitte nicht, dass das eine Led-Matrix wird... Nein, keine Matrix ;) Dafür gäbe es wesentlich elegantere Möglichkeiten als jeder LED einen extra µC zu verpassen :D Es wird ein anderes Beleuchtungsprojekt/Designprojekt, bis jetzt existiert die Idee aber nur in meinem Kopf ;)
nikolaus schrieb: > Es wird ein anderes Beleuchtungsprojekt/Designprojekt, bis jetzt > existiert die Idee aber nur in meinem Kopf ;) Mit der Hardwareauslegung sollte sie auch da bleiben.
Hmm mir wirkt das ganze auch etwas komisch. Beschreibe doch mal was es werden soll. Bin irgendwie so neugierig.
Hallo, schau dir doch mal an wie die Profis aus der Beleuchtungstechnuk das gelöst haben. Stichwort: DMX512 Gruss Stefan
DMX ist hier weder von der Hardware noch vom Protokoll her sinnvoll. RS-485 zur Kommunikation zwischen benachbarten Mikrocontrollern ist Overkill und das DMX-Protokoll unterstützt nur die Übertragung von 512Bytes, was hier offensichtlich nicht ausreicht. Mein Vorschlag: Wenns keine fertiger LED-Treiber sein soll würde ich zumindest nicht einen sondern mehrere Busse machen. Damit hält man die Datenrate auf jedem Bus niedrig und kann sich für jedes Bit etwas Zeit lassen. Leider gibt's mal wieder keine Infos zum Projekt, sonst könnte man evtl. noch sinnvollere Lösungen vorschlagen.
R2D2 schrieb: > Leider gibt's mal wieder keine Infos zum Projekt, sonst könnte man evtl. > noch sinnvollere Lösungen vorschlagen. Danke!
Ich würde ja damit anfangen, die völlig unnötige Auflösung von 8 Bit pro Farbe zu reduzieren.
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.