Guten Abend. Ich möchte gerne 24 bis 40 RGB Leds ansteuern (Bin noch nicht ganz sicher). Das alles macht der Atmega 8. Die Software ist bereits geschrieben und funktioniert auch wunderbar. Nun zu meinen Problemen: Ich möchte pro RGB Led ein Schieberegister einbauen. Eine RGB Led benötigt 3 Bits, doch z.B. der 4094'er schiebt 8 Bits durch, wobei dann 5 Bits nichts tun und damit wertvolle Rechenzeit verloren geht... Reinschieben muß ich sie ja doch :-) Kennt jemand ein 4 Bit Schieberegister, was die gleichen eigenschaften wie z.B. der 4094 hat? Ich bräuchte nämlich so einen Store eingang, damit die Bits erst zu den Ausgängen geschoben werden, wenn der Store Eingang auf high geht. Wenn ich das nicht habe, dann leuchten die Leds immer beim durchschieben, obwohl sie nicht leuchten sollen. Über Multiplexen hab ich mir auch schon gedanken gemacht, aber da ist mir erstens der Kabelaufwand zu groß und zweitens, wenn ich nur 24 RGB Leds mache will ich doch die Möglichkeit haben, irgendwann 40 RGB Leds anzusteuern. Ich finde da bin ich dann mit den Schieberegistern am flexibelsten, weil ich ja bei der letzten RGB Led einfach dazuhängen muß. Der Abstand von RGB zu RGB Led beträgt dann in meinem Fall ca. 50cm. Also ca. 12m bei 24 RGB Leds. Da mach ich mir natürlich auch sorgen, ob beim letzten Schieberegister die Daten noch korrekt ankommen. Wäre das möglich, bei jeden Schieberegister nach der Clock und nach den Data Ausgängen immer einen kleinen Transistor dranzuhängen? z.B. BC549...? Oder ist das totaler Schwachsinn? Würde das auch ohne funktionieren? Ich hoffe, ich habe es nicht zu kompliziert erklärt und es kann mir jemand weiterhelfen. Gruß Stefan
bei der Distanz stellt sich als erstes die frage nach der frequenz, mit welchem du die schieberegister betreiben willst. Bei einigen kHz wirds kein problem sein. Bei grössen frequenzen wäre z.b. interessant zu wissen wie die verbindung, etc aussieht... Das mit den Transistoren wäre möglich, hab mal was gemacht, wo ich auf verschiedenen prints schieberegister plaziert hab, und die signale auf jedem mit einem schmitt-trigger aufgefrischt habe, die idee war, das von den flankenanstiegszeiten/verzögerungszeiten immer die gleichen voraussetzungen herschen. Achte aber darauf, dass Flankenanstiegs- Abfals-zeiten unterschiedlich sind...
Wie wäre es denn mit 74HC573N da gibts du die Daten parallel aus und sagst welcher Baustein das Speichern soll, danach das gleiche mit dem nächsten Baustein, überträgst also erstmal alle Daten in mehrere Latches, wo das ganze gespeichert wird, dann schaltest du dei Eingänge der Latches hochohmig womit dein Port wieder voll zur Verfügung steht. Und gibts dann ein Signal aus damit sie alle gleichzeitig ihr Signal an die LEDs geben. Langwierige Schiebearbeit sparst du dir dadurch und kannst auch ziemlich schnell einzelne Leds ansprechen ohen alles komplett neu durchzuschieben. Habe mal ein Beispiel mit diesen Latches angehängt, wobei hier einige Funktionen des Bausteins garnicht erläutert werden. z.B. Transparent schalten, Eingänge Hochohmig schalten usw...
Hi. Klingt gut, ist aber wieder viel kabel aufwand. 3 kabel für rgb, 24 kabel für jeden latch, einmal 5v und einmal gnd sind dann 29 kabel. Mit den schieberegistern brauch ich da nur 5 kabel. Ist also ein großer unterschied. Gruß stefan.
Nein du brauchst nur einen Port für die Daten(alle Latcheingänge hängen parallel)wären also 8 und ein paar Steuerleitungen um das richtige Latch auszuwählen, der Port ist danach wieder frei zur Verfügung. Mehr Pins wirste also nicht benötigen wäre halt nur etwas mehr Aufwand des Verkabelns aber du hättest halt den Vorteil das du jedes Bit einzeln ändern kannst ohne alles komplett durchzuschieben.
Angehängte Dateien:
-
Schaltung.png
31 KB
Hallo Thomas. Hab im Anhang ein Bild drangehängt, so wie du es beschreibst. Ist nur ganz schnell gezeichnet ohne Vorwiderstände an den Leds. Nur zum erklären.. Hab das jetzt mit 3 RGB Leds gezeichnet. dazu brauch ich 3 Kabel zum Latch (RGB) und 3 Kabel, um auszuwählen, welches Latch gerade aktiv ist. Das macht 6 Kabel für 3 RGB Leds. Ich will aber mal 40 RGB Leds anschliesen... Dann rechne das mal aus:-) Also wie gesagt, jede RGB Led soll ihr eigenes Schieberegister bekommen, da ja zwischen den RGB Leds ca. 50cm Abstand sind. Kennt da sonst niemand eine Lösung?
@ Stefan (Gast) >Dateianhang: Schaltung.png (69,3 KB, 0 Downloads) Gings nicht noch grösser? 150 dpi reichen. >Hab das jetzt mit 3 RGB Leds gezeichnet. dazu brauch ich 3 Kabel zum >Latch (RGB) und 3 Kabel, um auszuwählen, welches Latch gerade aktiv ist. Nein. Es reichen 3 (DREI) Signale, um eine nahezu beliegbig grosse Anzahl LEDs zu steuern. Siehe AVR-Tutorial: Schieberegister >Das macht 6 Kabel für 3 RGB Leds. Ich will aber mal 40 RGB Leds >anschliesen... Dann rechne das mal aus:-) [ ] Du hast das Prinzip von Schieberegistern verstanden. >Also wie gesagt, jede RGB Led soll ihr eigenes Schieberegister bekommen, >da ja zwischen den RGB Leds ca. 50cm Abstand sind. Kein Thema, dann sind eben nur 3 von 8 Ausgängen genutzt. MfG Falk
Danke Falk, wie es mit Schieberegistern funktioniert, weiß ich auch. Wenn du weiter oben liest, was Thomas geschrieben hat, dann handelt es sich bei seinem Vorschlag aber nicht um Schieberegister, sondern um so einen Latch. Wenn jede RGB Led einen eignenen Lach hat, dann brauch ich alleine für jeden Latch ein Kabel... das mal 24 RGB Leds sind dann schon 24 Kabel. Darum will ich es ja mit Schieberegistern machen, da ich dann nur 5 Kabel brauche... Ich suche ein Schieberegister mit 4bit, damit nicht so viele Bits ohne Benutzung durchgeschoben werden.
Falk Brunner wrote: > >>Also wie gesagt, jede RGB Led soll ihr eigenes Schieberegister bekommen, >>da ja zwischen den RGB Leds ca. 50cm Abstand sind. > > Kein Thema, dann sind eben nur 3 von 8 Ausgängen genutzt. In dem Fall würde ich jeweils 2 RGB Led an 1 Schieberegister anschalten. Die 'Backbone' (4-Draht Bus) verbindet alle Schieberegister miteinander. Von jedem Schieberegisterbaustein, gehen jeweils 2 Stück 4-Draht Leitungen zu den RGB-Leds.
Das ist die sinnvollste Lösung, die Karl heinz Buchegger gerade vorgeschlagen hat! Solltest aber auf den sogenannten Fan-In aufpassen. Wenn du zuviele Module hast (also viele SCK parallel) dann wird das dem Treibenden Ausgang nicht gefallen ;-/
Hallo Matthias. Darum habe ich am Anfang gefragt, ob ich die Clock und die Daten jedesmal über einen Transistor schalten soll. Gruß Stefan
Stefan wrote: > Hallo Matthias. > > Darum habe ich am Anfang gefragt, ob ich die Clock und die Daten > jedesmal über einen Transistor schalten soll. > Ich sach mal so: Ich hab eine Schieberegisterkette aus 8 Stück 595 ohne irgendwelche Treiber dazwischen aufgebaut und sie funzt einwandfrei. Nach jeder Stufe einen Verstärker für CLK einzubauen ist sicherlich nicht notwendig. Bei den Daten braucht es sowas ja sowieso nicht, weil jeder 595 als Treiber für den nächsten fungiert.
Danke Karl Heinz, endlich mal eine nützliche Information. Hab im Internet gelesen, das man sich aus Flip Flops auch ein Schieberegister basteln kann. Hat da schon jemand Erfahrungen gemacht, wie Zuverlässig das ist? Kann man die dann schnell takten? Würde gerne mit mindestens 4MhZ takten.
Hör auf! Oder fällst du einen Baum, um Streichhölzer selbst
herzustellen??
>h jeder Stufe einen Verstärker ..
Ja, acht sind ok. Aber ab so 16 sollte man sich das überlegen..
12 Meter ist eine ordentliche Länge. Da treten echte Laufzeiten auf. Evtl. solltest Du die drei Datenleitungen am Ende mit eine RC-Glied gegen Ground abschliessen, sagen wir mal 10nF/220 Ohm. Ist nur so ein Gedanke für den Fall, dass es Probleme geben sollte. Ahso, und evtl. musst Du noch acht geben auf die Setup/Hold-Time der Latches wg. der gleichen Laufzeit.
Um maximale Geschwindigkeit zu erzielen, also maximalen Clock, noch ein Gedanke: Du willst ja nur drei Bits pro 4094 ausgeben. Es gibt also pro LED/4094 nur acht verschiedene Zustände, somit schreibst Du acht Routinen, wobei jede nur einen möglichen Zustand rausschiebt, ganz ohne Schleife. Somit kannst Du 24 LEDs mit AVR@16MHz in ca. 24 x 2us also 48us ansteuern.
@ Stefan (Gast) >Danke Falk, wie es mit Schieberegistern funktioniert, weiß ich auch. Das bezweifle ich. Wenn du den Link mal verfolgt, gelesen UND verstanden hättest, würdest du nicht so rumjammern und Unsinn erzählen. Aber lesen tut ja weh . . . >Wenn du weiter oben liest, was Thomas geschrieben hat, dann handelt es >sich bei seinem Vorschlag aber nicht um Schieberegister, sondern um so >einen Latch. Wenn jede RGB Led einen eignenen Lach hat, dann brauch ich >alleine für jeden Latch ein Kabel... das mal 24 RGB Leds sind dann schon QUARK! Link lesen und verstehen! Es reichen DREI Signale! Ein 74HC595 ist Schieberegister + Latch! @ Karl heinz Buchegger (kbuchegg) >Die 'Backbone' (4-Draht Bus) verbindet alle Schieberegister Warum 4? Drei reichen, plus VCC/GND! @ Stefan (Gast) >wie Zuverlässig das ist? Kann man die dann schnell takten? Würde gerne >mit mindestens 4MhZ takten. LESEN. MEIN LINK! @ Chrisi (Gast) >12 Meter ist eine ordentliche Länge. Da treten echte Laufzeiten auf. >Evtl. solltest Du die drei Datenleitungen am Ende mit eine RC-Glied >gegen Ground abschliessen, sagen wir mal 10nF/220 Ohm. Ist nur so ein Die 10nF Sind viel zu viel! maximal 1nF, eher vielleicht 470pF. >musst Du noch acht geben auf die Setup/Hold-Time der Latches wg. der >gleichen Laufzeit. Ein AVR ist trotz 20 MHz Takt immer noch langsam im Verhältnis zum Schieberegister. Erst recht bei Soft-SPI. MfG Falk
Hallo Falk. Will jetzt auf keinen Fall mit Dir hier herumstreiten, aber Thomas O. hat nicht ein Schieberegister 74HC595 gemeint sondern einen 74HC573N. Glaube kaum, das der 74HC573N ein Schieberegister ist, den man mit 5 Leitungen steuern kann... Deshalb hab ich auch geschrieben: >Hi. Klingt gut, ist aber wieder viel kabel aufwand. 3 kabel für rgb, 24 >kabel für jeden latch, einmal 5v und einmal gnd sind dann 29 kabel. Mit >den schieberegistern brauch ich da nur 5 kabel. Ist also ein großer >unterschied. Ich will es ja mit Schieberegistern machen (5 Leitungen). Warum drehst du mir das Wort im Mund um? :-) Eigentlich wollte ich ja nur wissen, ob jemand ein 4bit Schieberegister kennt, das die gleichen eigenschaften wie eine 74HC595 oder ein 4094'er hat. Der 40195 ist zwar ein 4bit Schieberegister, jedoch gibt er die Daten schon beim schieben aus, da er keinen Latch besitzt. Sehe ich das richtig? Allerdings ist auch der Datenausgang (zum kaskadieren von mehreren Schieberegistern) bei dem 40195 immer invertiert, was auch wieder ein kleines Problem darstellt. Ich hoffe es gibt keine Mißverständnisse mehr und jemand kann mir weiterhelfen. Danke
Angehängte Dateien:
-
Latch2.png
11 KB
ich habe es so gemeint, um so länger deine Schieberegisterkette wird desto länger dauert es halt auch alles durchzuschieben, mit den Latches kannst du halt direkt z.B. das 5te Latch ansprechen und dem die Daten übermitteln. Man könnte auch ein Latch hernehmen womit man die ganzen Steuersignale an die anderen Latches übermittelt.
Wenn ihr das schon so aufbaut (wie im bild von Thomas O. (kosmos), 07.08.2007 06:22) dann könnt ihr gleich die Latches in den RAM einblenden! Da spart ihr euch dann den Trödel mit dem Latcheingang. Schreiben in einem (asm)Befehl..
@ Matthias L. (lippy) >Wenn ihr das schon so aufbaut (wie im bild von Thomas O. (kosmos), >07.08.2007 06:22) dann könnt ihr gleich die Latches in den RAM >einblenden! >Da spart ihr euch dann den Trödel mit dem Latcheingang. Schreiben in >einem (asm)Befehl.. Da gibt es nur ein "kleines" Problem. Die latches sind bis zu 12m auseinander. Und glaubst du wirklih, dass du über diese Kabellängen einen AVR mit voller Geschwindigkeit zugreifen lassen kannst? Mfg Falk
Thomas O. wrote: > ich habe es so gemeint, um so länger deine Schieberegisterkette wird > desto länger dauert es halt auch alles durchzuschieben, mit den Latches > kannst du halt direkt z.B. das 5te Latch ansprechen und dem die Daten > übermitteln. Man könnte auch ein Latch hernehmen womit man die ganzen > Steuersignale an die anderen Latches übermittelt. Den interessanten Teil, nämlich die Adressierung über die EN-Eingänge, hast du unter den Tisch fallen lassen :-)
Angehängte Dateien:
-
Bild.png
5,8 KB
Hi Hab mir da heut ein paar Gendanken gemacht, und dann hatte ich eine Idee. Ich könnte einen 4015'er als 3bit Schieberegister nehmen. Einfach beim Dritten Ausgang direkt zum nächsten Dateneingang. Dadurch würde ich nichteinmal ein bit verlieren. Natürlich kommt dann noch zwischen den Leds und den Schieberegistern ein Latch zum Einsatz, damit die Leds beim durschieben nicht blinken. Könnte das so funktionieren, oder hab ich da einen Denkfehler drin? Bild im Anhang. Vielen Dank
das könnte man mit einem 4 to 16 (74HC4514/4515)(oder kleiner z.B. 3 to 8) Decoder machen dann wären bis zu 16 Latches möglich. Bei nur 40 Leds wird man aber mit den Schieberegistern besser dran sein, wenn die Anwendung den µC sonst nicht auslastet. Matthias L: Man sollte sowieso für jedes Latch ein Byte im SRAM reservieren oder besser ein Register wenn man nicht alles benötigt. Dann ändert man nur die entsprechenden Bits und schickt es zum entsprechenden Latch.
Hallo Thomas. Nur ganz kurz. Bedenke, das 40 RGB Leds insgesammt 120 Leds sind.
Anderer Lösungsweg: Häng pro LED einen ATTiny dran. Der kostet auch nur nen Euro, ist also nicht viel teurer als Schieberegister+Latch, kann die LEDs direkt treiben, und die PWM "vor Ort" machen. Die Einzelmodule wären dann Platinchen mit LED, 3 Widerständen, dem Tiny, und nem Kondensator. Du kommst mit drei Leitungen in deinem Bussystem aus (GND,VCC,Data), kannst ein langsames serielles Protokoll fahren, und hast keinen 4MHz Antennendraht quer durch dein Zimmer verlegt. Dein Haupt-Atmega spart sich jede Menge Rechenzeit (72 Soft-PWM-Kanäle über Schieberegister sind kein Pappenstiel) und du kannst die PWM-Auflösung viel höher drehen => Schönere Farbübergänge. Als Protokoll würden warscheinlich Packets aus 4 Bytes reichen, <modulnummer> <red> <green> <blue> Einfach über den UART Ausgeben, evtl Treiber dahinter, und bei jedem Modul über den UART wieder einlesen. Parity-Bit kannst du "kostenlos" mit dazuschalten. Und je nach Gusto kannst du auch noch mehr Intelligenz in die Module verpacken, z.B. eine HSV->RGB Umrechnung, automatisches Anfahren eines Ziel-Farbwerts etc. /Ernst
Hallo Ernst. Danke für Deine Antwort. Klingt sehr interessant. Nur denke ich, das es zu langsam ist. Laut AVR Studio braucht ein byte 1 ms zum senden. Und dann mal 4 <modulnummer> <red> <green> <blue> und mal 24 leds. Das sind dann 96 ms wenn ich an alle leds neue daten schicke. Wenn ich jetzt z.B. alle Leds auf den Wert 255 eindimmen will, dann dauert das 25 Sekunden. Lieg ich da richtig? Ach ja, was ist ein Parity-Bit?
> Laut AVR Studio braucht ein byte 1 ms zum senden.
Wie kommst du jetzt darauf?
Übrigens ist das auch eine Frage des Protokolls. Kannst ja auch mit
Broadcasts arbeiten, d.h. "an Alle: eine Stufe heller bitte!".
Andreas Kaiser wrote: >> Laut AVR Studio braucht ein byte 1 ms zum senden. > > Wie kommst du jetzt darauf? Ja, diese Aussage ist so, wie sie da steht Mist! Meinst du mit dem UART? Das kann man auch etwas höher drehen. Mit 1MHz (1MBaud) hast du zwar auch wieder ein Antennenkabel, aber nur 10µs pro Byte.
> Meinst du mit dem UART? Das kann man auch etwas höher drehen. Mit 1MHz > (1MBaud) hast du zwar auch wieder ein Antennenkabel, aber nur 10µs pro > Byte. Mit 1Mbps UART bringst du jetzt aber den armen Tiny etwas in Bedrängnis. SPI-Slave (USI) kann er besser, jedenfalls neuere Versionen.
So schnell kann man den UART nicht machen, die kleinen 8pin Tinies bräuchten sonst nen Quarz-Oszillator. Ansonsten könnten die ihren internen RC regelmässig nachjustieren, der Master schickt eine dummy-Sequenz (z.B. 0x55 0x55...) und die Tinies drehen an ihrem OSCAL. Hast du eigentlich schon ausprobiert ob dein ATMega8 dir 72PWM-Kanäle berechnen und über SPI ausgeben kann, ohne daß das ganze zu nem 24-Lampen-Stroboskop wird? /Ernst
Auwe, ich dache das man eine baudrate von 9600 nehmen muß, weil das so im tutorial steht. Also geht das doch schneller. Kann vielleicht noch jemand sagen, ob die Schaltung mit dem 4015 generell funktionieren könnte?
Ja Ernst. Die Software steht und ich habe sie auch schon mit SPI auf einen 4094 ausgegeben. Mit 100 Hz. Das einzige was ich reduziert habe, sind die Farben. Ich habe halt nur 128 Helligkeiten. Aber sonst geht sich zeitlich alles schön aus.
Stefan wrote: > Kann vielleicht noch jemand sagen, ob die Schaltung mit dem 4015 > generell funktionieren könnte? Generell schon, aber du hast keine Latches vor den LEDs, deswegen kannst du an denen schön den Datentransfer beobachten. Und nachdem du warscheinlich ununterbrochen am Datenübertragen bist, werden nachher alle LEDs mehr oder weniger gleichhell leuchten, egal was du überträgst. Wenn du aber nur einmalig eine Einstellung überträgst, und vor der nächsten Übertragung lange wartest gehts. PWM is dann aber nicht mehr, d.H. nur 7 mögliche Farben pro RGB-LED. Edit: Ups, hätte den Text genauer lesen sollen. Wenn du da ein Latch mit einbaust, klappts.
Ich habe ja bei dem Schaltbild dazugeschrieben, das der dazugehörige latch nicht eingezeichnet ist, weil das ja nicht das Problem ist.
@ Stefan (Gast):
Ja, die Schaltung funktioniert so.
>>ich dache das man eine baudrate von 9600 nehmen muß
Das ist ja genial. 9600Baud..
Bei 16MHz Quartztakt kannst du bis zu 2MEGAbaud realisieren...
Aber die Idee mit den vielen tinys (die ja alle dasselbe Programm
haben-nur ne andere Knotenadresse) finde ich am besten.
Aber es ist vielleicht noch besser, die tinys mittels SPI zu verbinden:
So sparst du dir die Modulnummer im Protokoll, weil die anordnung in der
daisy-chain entscheidet.
Die sendest immer nur drei bytes (RGB) für jedes Modul. Musst aber in
diesem Fall immer alle senden...
Wäre mal zu überlegen...
Guten Abend.. Ich hab mir jetzt mal ein par AVR Datenblätter durchgesehen und der einzige der dazu passen könnte, wäre der AT-Tiny 2313. Er hat Hardware USART(Ich hoffe, das ist auch UART) und 4 Hardware PWM Ausgänge, wo dann 3 PWM im Programmhintergrund laufen. Wenn ich dann was mit dem M8 senden will, dann könnte ich es mit einem Interupt machen. Würde das so funktionieren? Gruß Stefan
Danke für die Antwort Falk. Hätte aber jetzt noch eine Frage. Ich habe mal gehört, das man spezielle Quarze nehmen sollte, damit das UART sauber funktioniert. Ist das richtig oder kann ich problemlos einen 16 MhZ bei allen Tiny2313 verbauen? Gruß Stefan
@ Stefan (Gast) >Ich habe mal gehört, das man spezielle Quarze nehmen sollte, damit das >UART sauber funktioniert. Ist das richtig oder kann ich problemlos einen Du meinst Baudratenquarze. Kann man nehmen, muss man aber nicht. >16 MhZ bei allen Tiny2313 verbauen? Kommt darauf an, welche Baudrate du haben willst. 115k2 gehen mit 16 MHz nicht! Siehe Datenblatt sowie AVR-Tutorial: UART MfG Falk
Hallo Falk. Danke für die Antwort. Ich werde mich dann wohl für den 12.288 MhZ entscheiden.
1 | Ernst Bachmann schrieb: |
2 | |
3 | Als Protokoll würden warscheinlich Packets aus 4 Bytes reichen, |
4 | <modulnummer> <red> <green> <blue> |
Dabei hab ich aber ein Problem. Nehmen wir an, mein dritter Tiny hat die Adresse 0x03. Also gebe ich über das Uart 0b00000011 aus. Alle 24 Tinys lesen die Daten ein und vergleichen sie mit den mir vorgegebenen Modelnummern. Da nur der dritte 0x03 hat, fühlt sich nur er angesprochen. So.... Und jetzt möchte ich, daß beim dritten Tiny die rote Led mit der Helligkeit 0x04 bei 8 bit Auflösung leuchtet und schicke das über das Uart. Das Problem ist dann nur, das sich dann der vierte Tiny angesprochen fühlt. Wie kann ich dieses Problem lösen? Sollte ich da bei allen anderen den Uart Empfang für kurze Zeit ausschalten, wenn sie sich nicht angesprochen fühlen? Ich dachte auch schon darüber nach, die Pwm auf max. 0x80 zu beschränken und die Modelnummern dann über 0x81..0x82...usw zu machen. Nur ist da das Problem, das die Hardware PWM aus 8 bit besteht und die Leds dann nicht so hell leuchten. Aber die Helligkeit könnte man dann wieder mit einem geringeren Widerstand ausgleichen. Was würdet ihr mir vorschlagen? Gruß Stefan
Dein Protokoll sieht das Versenden von VIER Bytes vor. Definiere doch danach eine Pause von etwas mehr als 1Byte Länge*. Somit hat deine Empfangsroutine die möglichkeit, ein Paketende in Form eines TimeOuts zu erkennen(und kann jetzt das Paket auswerten). Zusätzlich, um die Prozessorlast zu senken, kannst du den "multi processor communication mode" (MPCM) dafür verwenden. Der ist für solche Sachen bestens geeignet. Hab ich auch schon für ähnliche Anwendungen verwendet. Weitere Hinweise zu MPCM: siehe Datenblatt des Atmels unter UART. * bevor ein neues Paket gesendet werden darf EDIT: Mit dem MPCM kannst du auch direkt nach drei Empfangenen Nutzdaten(RGB) wieder auf "Adresse empfangen" umschalten. Somit kann der TimeOut im Protokoll auch gegelassen werden. (In der Software würde ich ihn drin lassen, falls nach den ersten,zweiten Datenbyte die Übertragung abbricht, könnte man so das Paket verwerfen). Dadurch käönntest du "ununterbrochen" Pakete herausballern...
@ Stefan (Gast) >Als Protokoll würden warscheinlich Packets aus 4 Bytes reichen, ><modulnummer> <red> <green> <blue> >0x03 hat, fühlt sich nur er angesprochen. Naja, es muss/sollte eben ein Datenpaket eindeutig abgrenzbar sein. Z.B. indem man ein konstantes Byte immer als Startsymbol sendet. Ausserdem müssen die Slaves nach relativ kurzer zeit einen Timeout erzeugen und wieder auf das Startzeichen warten. >allen anderen den Uart Empfang für kurze Zeit ausschalten, wenn sie sich >nicht angesprochen fühlen? Nein, nicht dem Empfang ausschalten, aber ihre interen Programmlogik wieder auf das Suchen des Startzeichens setzen. >Ich dachte auch schon darüber nach, die Pwm auf max. 0x80 zu beschränken >und die Modelnummern dann über 0x81..0x82...usw zu machen. Nur ist da >das Problem, das die Hardware PWM aus 8 bit besteht und die Leds dann >nicht so hell leuchten. Aber die Helligkeit könnte man dann wieder mit Du kannst doch einfach die PWM-Werte in den Slaves wieder mit 2 multiplizieren, 1 mal links schieben und schon hast du wieder einen vollen 8 Bit Wert, nur eben mit halber Auflösung, das reicht aber immer noch. >einem geringeren Widerstand ausgleichen. Nein! MFG Falk
Vielen Dank ihr 2. Hab es jetzt mit rol gelöst, so wie es Falk gemeint hat. Und es klappt alles bestens. Vielen Dank für Eure Hilfe. Gruß Stefan
@ Stefan (Gast)
>Hab es jetzt mit rol gelöst, so wie es Falk gemeint hat. Und es klappt
Mach mal lieber lsr, mit rol "saugst" du dir das Carryflag ins LSB, das
kann auch mal daneben gehen.
MFg
Falk
Du meinst lsl.. ich muß ja linksschieben. Mit lsr dividiere ich ja durch 2. Gruß Stefan
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.