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.
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 ;-/
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
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 :-)
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.
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.
@ 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
@ 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
