[Sammelbestellung] Digitaler RGB-LED-Strip

danbruc · 15. Januar 2011

Hallo zusammen,
ich hätte auch Interesse an (mindestens) einem adressierbaren RGB-LED-Strip.

5+ Meter Länge
30+ LEDs pro Meter
1 LED pro Pixel
24 Bit Farbtiefe (richtig ansteuerbar wie beim WS2801, nicht fixe Funktionen wie beim HL1606)
50+ Hz Wiederholrate bei 5 Meter Länge
Synchrone Übernahme der Daten aller Chips in die PWM-Module
Standardinterface wie SPI und einfaches Protokoll für die Ansteuerung bevorzugt
Gegen Wasser geschützt (IPx4+) wäre auch schön

turi: Passen die Stripes, die du hast, zu meinen Wünschen?

turi · 15. Januar 2011

Herzlich Willkommen im Forum. Also die Stripes sind ja mit dem WS2801 mit 32 LEDs/m ("Digitaler RGB-Strip" mit WS2801). Damit sollten die grundsätzlich den Anforderungen entsprechen. Allerdings sind sie als Indoor-Version ausgelegt. Sie haben zwar einen Silikon-Überzug, jedoch sind die Stecker nicht wasserdicht ausgelegt. Aber prinzipiell lassen sich auch wasserdichte besorgen.

danbruc · 15. Januar 2011

Danke für das Willkommen.
Inzwischen habe ich auch deine Homepage entdeckt und mir die Fotos dort und in dem verlinkten Beitrag genauer angeschaut. Es sind also 1-Meter-Stücken oder gibt es die auch länger? Nach dem Vergleich der Platinen auf den Fotos würde ich sagen, es sind die selben, die es bei Sparkfun gibt, nur mit schwarzer statt weißer Platine.
Was mich bis jetzt davon abgehalten hat, 1-Meter-Stücken zu nehmen ist, dass ich einen regelmäßigen Abstand der LEDs über die gesamte Länge benötige. Ich könnte zwar einfach die Anschlüsse abschneiden und die Elemente passend zusammen löten, aber das würde ich lieber vermeiden. Sind die Anschlüsse kurz und flexibel genug, so dass man die umbiegen und zwei Elemente nah genug für einen gleichmäßigen Abstand zusammen bekommen kann?

turi · 15. Januar 2011

Wir sind hier eigentlich im falschen Thread unterwegs. Sorry an den TE. Es scheinen ansonsten wirklich die gleichen Teile zu sein. Längen über 2m sind nicht sinnvoll, da ansonsten die Einspeisung von beiden Seiten erfolgen müsste. Es gibt die auch in 2m Länge,ja.

Wenn man die Lückenlos aneinander haben möchte, sollte man aber vielleicht doch wenigstens an einer Seite das Kabel entfernen. Das ist zwar Litze und flexibel, aber muss ja auch irgendwo hin gebogen werden.

BadDeath · 28. Januar 2011

Nabend!

So, ich habe mir nun von 2bl die 50cm mit den TM1804 ausleihen können und versuche nun vergebens sie anzusprechen.
Dazu nutze ich einen Arduino mit folgendem Programm:

Code

static int pin = 3;




void setup()
{
  pinMode(pin, OUTPUT);
}


void loop()
{
  // for all 5 chips do:
  for (int i = 0; i <= 4; i++)
  {
	// red
	LowBit();
	LowBit();
	LowBit();
	LowBit();
	LowBit();
	LowBit();
	LowBit();
	LowBit();


	//blue
	HighBit();
	HighBit();
	HighBit();
	HighBit();
	HighBit();
	HighBit();
	HighBit();
	HighBit();

	//green
	HighBit();
	HighBit();
	HighBit();
	HighBit();
	HighBit();
	HighBit();
	HighBit();
	HighBit();
  }

  Reset();

  delay(5000);
}






void HighBit()
{
  // 21 x 62,5 ns = 1312,5 ns
  digitalWrite(pin, HIGH);
  __asm__("nop\n\t" "nop\n\t" "nop\n\t" "nop\n\t" "nop\n\t" "nop\n\t" "nop\n\t" "nop\n\t" "nop\n\t" "nop\n\t" "nop\n\t" "nop\n\t" "nop\n\t" "nop\n\t" "nop\n\t" "nop\n\t" "nop\n\t" "nop\n\t" "nop\n\t" "nop\n\t" "nop\n\t");


  //  11 x 62,5 ns = 687,5 ns
  digitalWrite(pin, LOW);
  __asm__("nop\n\t" "nop\n\t" "nop\n\t" "nop\n\t" "nop\n\t" "nop\n\t" "nop\n\t" "nop\n\t" "nop\n\t" "nop\n\t" "nop\n\t");
}




void LowBit()
{
  digitalWrite(pin, HIGH);
  __asm__("nop\n\t" "nop\n\t" "nop\n\t" "nop\n\t" "nop\n\t" "nop\n\t" "nop\n\t" "nop\n\t" "nop\n\t" "nop\n\t" "nop\n\t");


  digitalWrite(pin, LOW);
  __asm__("nop\n\t" "nop\n\t" "nop\n\t" "nop\n\t" "nop\n\t" "nop\n\t" "nop\n\t" "nop\n\t" "nop\n\t" "nop\n\t" "nop\n\t" "nop\n\t" "nop\n\t" "nop\n\t" "nop\n\t" "nop\n\t" "nop\n\t" "nop\n\t" "nop\n\t" "nop\n\t" "nop\n\t");
}






void Reset()
{
  digitalWrite(pin, LOW);
  delayMicroseconds(24);
  digitalWrite(pin, HIGH);
}

Alles anzeigen

Nun sind auf dem Streifen fünf Chips verbaut, welche doch eigentlich alle gleb leuchten müssten, oder?
Jedoch leuchten gerade mal die LEDs des ersten Chips und zwar weiß. Aber immerhin, sie leuchten

Meiner Meinung nach müssten ja auch die Timings stimmen. Das einzige brauchbare, was ich überhaupt zu dem Chip finden konnte ist ein chinesisches Datenblatt:
http://www.tonshine.com/UploadFiles/2009127174050945.pdf
Auf Seite sieben sind die Timings zu finden.

Bitte helft mir

Leuchtidiot · 28. Januar 2011

RGB(00000000,11111111,11111111) gibt aber türkis, nicht gelb.

Aber hilft dir ejtzt nichts, weild as kommt bei dir ja net raus

BadDeath · 28. Januar 2011

Danke für den Hinweis, aber ich komme einfach nicht weiter. Im Gegenteil: es entstehen mir unerklärliche Fehler bei diesem Code:

Code

void loop()
{
  Reset();
  digitalWrite(13, HIGH);   //TEST-LED, hat nix mit dem Strip zu tun
  delay(5000);
  digitalWrite(13, LOW);

  // for all 5 chips do:
  for (int i = 1; i <= 5; i++)
  {
	// red
	HighBit();
	HighBit();
	HighBit();
	LowBit();
	LowBit();
	LowBit();
	LowBit();
	LowBit();

	//green
	LowBit();
	LowBit();
	LowBit();
	LowBit();
	LowBit();
	LowBit();
	LowBit();
	LowBit();

	//blue
	LowBit();
	LowBit();
	LowBit();
	LowBit();
	LowBit();
	LowBit();
	LowBit();
	LowBit();
  }
}

Alles anzeigen

(der Rest bleibt gleich)

Nach 5 Sekunden wird der erste Pixel weiß und nach einiger Zeit, so um die 20 Sekunden, wird der zweite Pixel grün. Egal, wie ich die Farbbits kombiniere.
Doch eigentlich sollten die Farben maximal aufblinken und dann wieder ausgehen (5 Sekunden Pause nach dem Reset). Also scheint nicht mal der Reset zu funktionieren

Ich habe einfach keinen Einfall mehr....... HILFE!!!!

BadDeath · 31. Januar 2011

Bitte verzeiht mir den Doppel-Post, aber will oder kann mir keiner helfen?

2bl · 31. Januar 2011

Also ich habe den TM1804 noch nicht selbst angesteuert, sondern nur einen fertigen Controller benutzt.
Mit diesem funktionierte es aber einwandfrei.

Zur Not koennte ich diesen mal an das dicke Oszi in der Uni anklemmen, und eine Sequenz zum re-engineering aufzeichnen...

Ansonsten sind mit zufaellige und zeitlich unabhaengige Farben auch schon beim LPD-6803 untergekommen, immer dann wenn in der Software des Controllers falsche Timingparameter oder Chiprevisionen eingestellt wurden. Wenn also ein Pixel irgendwann tyrkis wird, bedeutet das nicht, das auch der Controller irgendwas davon "gesagt" hat!

Weiterhin ist hier noch ein recht ausfuehrlicher Thread ueber den TM1804:http://forums.auschristmasligh…ndex.php/topic,686.0.html

Da wird auf einige Timingparameter eingegangen, und ist auch sonst ganz interessant zu lesen.

Viel Erfolg!

Andre

BadDeath · 31. Januar 2011

Ja, das mit der Sequenz wäre super! Wenn ich pausenlos einfach nur 1x HIGH in der Mainloop sende, sind zwar alle Pixel weiß, aber der erste flackert ziemlich und der zweite noch ein wenig.....

Den Thread von den "Weihnachtsbeleuchtern" habe ich auch schon finden können und auch schon deren Timings probiert, aber es will nichts helfen. Dann habe ich mich heute noch durch eine chin. Seite geplagt (+ Registrierung) um ein weiteres Datenblatt zu dem Chip runterzuladen, aber da steht scheinbar genau das selbe drin, wenn ich dem Google-Übersetzer vertrauen kann

2bl · 31. Januar 2011

Sorry wenn ich jetzt nochmal bloed frage, aber Du hast schon den GND vom Arduino mit dem GND der Stromversorgung verbunden, oder? Aus den Strip kommen ja extra zwei Leitungen hierfuer raus, die auf dem Strip zusammengeschaltet sind...

BadDeath · 31. Januar 2011

Naja, wie du eben schon geschrieben sind: sind im Strip miteinander verbunden. An die Buchse vom Strip habe ich einfach nen 12V-Schaltnetzteil gehängt und vom Arduino habe ich GND auch zum Strip gelegt.

Pesi · 31. Januar 2011

Im Arduino laufen ja nebenher auch noch Timer(-Interrupts) für Wartezeiten etc. - kann schon sein, dass Dir da ab&zu beim Puls erzeugen einer dazwischen haut, und damit dann natürlich die Länge ändert...

ausserdem weißt Du nicht, was der da nun genau macht bei " digitalWrite(pin, HIGH);", wenn das schlecht umgesetzt ist, kann das auch ein paar Takte dauern...

also würde ich den Puls komplett in Assembler erzeugen, und zwar atomar (= ohne Störung, in einem Stück):

Code

cli ; Interrupts verhindern
sbi PortB, 5 ; oder wo auch immer dieser "Digital-Pin" dran hängt
nop ; so viele, wie Du halt brauchst
nop
nop
cbi  PortB, 5 ; oder wo auch immer dieser "Digital-Pin" dran hängt
sei ; interrupts wieder freigeben

und der Reset ist nur 24 µs low - danach nicht wieder auf High stellen, weil der nächste Puls fängt ja wieder mit einer low-high-Flanke an, die kannst Du ja nicht machen, wenn der Pin schon high ist...

BadDeath · 31. Januar 2011

Dann muss ich mir wohl doch mal Assembler genauer ansehen - schaden kann es ja nicht...

Muss man für "cbi PORTD, 3\n\t" noch PORTD definieren? Der Comiler spuckte mir immer das hier aus:

Zitat

/tmp/cc3I8OVF.s: Assembler messages:
/tmp/cc3I8OVF.s:619: Error: constant value required

Nun habe ich es damit probiert: Sollte ja eigentlich auch schnell genug sein:

Code

void HighBit()
{
  PORTD = B00001000;
  __asm__("cli\n\t" "nop\n\t" "nop\n\t" "nop\n\t" "nop\n\t" "nop\n\t" "nop\n\t" "nop\n\t" "nop\n\t" "nop\n\t" "nop\n\t" "nop\n\t" "nop\n\t" "nop\n\t" "nop\n\t" "nop\n\t" "nop\n\t" "nop\n\t" "nop\n\t" "nop\n\t" "nop\n\t" "nop\n\t");


  PORTD = B00000000;
  __asm__( "nop\n\t" "nop\n\t" "nop\n\t" "nop\n\t" "nop\n\t" "nop\n\t" "nop\n\t" "nop\n\t" "nop\n\t" "nop\n\t" "nop\n\t" "sei\n\t");
}

Nur bringe ich damit gerade mal alle Pixel auf weiß - aber ohne Flackern!! Ich komme dem Ziel näher, wenn auch in sehr kleinen Schritten.

PS: Mittlerweile ist's Pin 3, also schon mal ein "Fehler", der ausgeschlossen werden kann.

Aber ich danke bereits!

Pesi · 31. Januar 2011

Wie ist das denn, wenn Du lauter Nullen rausgibst, werden dann trotzdem alle Pixel weiß....?

Oder gehen die verloren, also in der Art 00000000 11111111 11111111 ergibt dann nicht türkis, sondern gelb, weil am Chip praktisch nur 11111111 11111111 ankommt...?

in einem Fall ist der "0"-Puls dann zu lang, im anderen wohl zu kurz (?)

würde da auf jeden Fall mal bisschen rumprobieren, also die Länge des "0-Pulses" mal variieren...

BadDeath · 31. Januar 2011

Ja, auch wenn ich nur Nullen sende, sind alle weiß. Ich habe es nun mit versch. Timings probiert, T0H länger/kürzer T0L länger/kürzer, T0 genauso wie T1 - aber es will einfach nicht. Man hat ja auch +-150ns Toleranz, also sollte ein NOP nun mit den 62,5ns soviel aus machen.

Hätte ich ein Oszi, könnte ich ja mal gucken, wie lang die Bits nun wirklich sind, die der ATmega rausschickt. Aber diese kurzen Momente kann ich leider mit nix messen. Und nen Logik-Analysator habe ich erst recht nicht.

Edit: Also ich habe mal eben geguckt und meiner Ansicht nach ist der Pin SET am TM1804 unverbunden, schwingt also frei?! Nach der Übersetzung des Datenblattes zu dem Pin heißt es "SET-Modus eingestellt ist auf VDD nehmen: Low-Speed-Modus; besetzen: High-Speed-Modus". Also wenn er auf LOW ist, ist der High-Speed-Modus? Somit müsste der nicht verbundene Zustand ja als LOW gelten und die Timings wären nach http://forums.auschristmasligh…a44ec3be460e9b679#msg5656 die Hälfte.

Nun blinken alle Pixel irre schnell und bunt umher, wenn ich einfach nur Nullen durchschiebe. Sende ich bspw. RGB(0,255,0), kommt zu dem bunten Rumgeflackere noch ein statisches Weiß dazu. Bei nur Einsen ist wieder einfach alles nur weiß, das läuft wie gehabt

BadDeath · 1. Februar 2011

Puuhhh, ich scheine es doch geschafft zu haben!! Es sind wirklich die Zeiten aus dem Datenblatt (ich habe das von Titan Micro Electronics) zu halbieren. Das hatte ich gestern eigentlich auch schon gemacht, bildete ich mir ein, aber naja, nun gehts

Für, die es interessiert:

Code

#define cbi(port, bit) (port) &= ~(1 << (bit))
#define sbi(port, bit) (port) |= (1 << (bit))


void HighBit()
{
  sbi(PORTD,3);
  __asm__("cli\n\t" "nop\n\t" "nop\n\t" "nop\n\t" "nop\n\t" "nop\n\t" "nop\n\t" "nop\n\t" "nop\n\t" "nop\n\t" "nop\n\t");


  cbi(PORTD,3);
  __asm__("nop\n\t" "nop\n\t" "nop\n\t" "nop\n\t" "sei\n\t");
}




void LowBit()
{
  sbi(PORTD,3);
  __asm__("cli\n\t" "nop\n\t" "nop\n\t" "nop\n\t" "nop\n\t");


  cbi(PORTD,3);
  __asm__("nop\n\t" "nop\n\t" "nop\n\t" "nop\n\t" "nop\n\t" "nop\n\t" "nop\n\t" "nop\n\t" "nop\n\t" "nop\n\t" "sei\n\t");
}




void Reset()
{
  cbi(PORTD,3);
  delayMicroseconds(24);
}

Alles anzeigen

Nun geht allerdings die Reset-Funktion noch nicht, aber das denke ich bekomme ich auch noch hin, oder hat jemand schon ne Idee? Mit versch. Zeiten wie 12us, 20us, 30us und so habe ich es auch schon probiert.

Und achja: Zumindest ist bei dem Strip (eigentlich der von 2bl) Rot und Grün vertauscht

Danke nochmal an Pesi und an 2bl!

2bl · 1. Februar 2011

Hey!

Cool, schoed das es doch noch funktioniert!
Ja, letztenendes musstte es ja alles eine Frage des Timings sein. In meinem Controller war wohl default-maessig der richtige Modus (high/lowspeed) aktiviert...

Das heisst Du kannst momentan exakt ein "Frame" an den Stripe schicken?
Na immerhin, das mit dem Reset wird sicher auch noch!

Vielleicht komme ich ja morgen mal dazu, das Signal meines Controllers aufzuzeichnen.

Viele Gruesse und viel Erfolg weiterhin!
Andre

BadDeath · 1. Februar 2011

Ja, ich kann nun ohne Probleme alle 5 Pixel einzeln ansteuern. Nur wenn ich alle mit RGB(0,0,0) und die Mainloop ohne delay durchrattern lasse, blinken die Pixel leicht und willkürlich bunt umher...
Nun habe ich auf Arbeit mein Notebook-Netzteil vergessen und kann nun nicht wirklich damit heute abend weiter machen Aber werde dann erstmal den typischen Farbverlauf machen und dann mein eigentliches Vorhaben testen. (Darf ich den bitte bitte bitte noch über's WE haben?)

Achso, und kennt jemand ne Idee das hier auch ein wenig schöner zu lösen:

Code

void RGB(byte r, byte g, byte b)
{
  WriteByte(g);
  WriteByte(r);
  WriteByte(b);
}


void WriteByte(byte b)
{
  if (b & B10000000) {
	HighBit();
  } 
  else {
	LowBit();
  }  	


  if (b & B01000000) {
	HighBit();
  } 
  else {
	LowBit();
  }  	


  if (b & B00100000) {
	HighBit();
  } 
  else {
	LowBit();
  }  	


  if (b & B00010000) {
	HighBit();
  } 
  else {
	LowBit();
  }  	


  if (b & B00001000) {
	HighBit();
  } 
  else {
	LowBit();
  }  	


  if (b & B00000100) {
	HighBit();
  } 
  else {
	LowBit();
  }  	


  if (b & B00000010) {
	HighBit();
  } 
  else {
	LowBit();
  }


  if (b & B00000001) {
	HighBit();
  } 
  else {
	LowBit();
  }
}

Alles anzeigen

Pesi · 1. Februar 2011

In Assembler würde man ne Schleife machen die 8x durchläuft, immer das Byte eins nach links durch's Carry rotieren, wenn Carry gesetzt, dann Bit1 ausgeben, wenn nicht, dann Bit0 - so in der Art müsste das in C doch auch machbar sein...? - also da kann man doch bestimmt auch Rotieren und je nach Carry gesetzt oder nicht dies oder das machen...?

übrigens, weil ich mal gemeint habe, dass man schon mehr Rechenpower braucht, um die Daten an 8 Ausgängen auszugeben, so wie dieser Onumen-Controller: stimmt gar nicht, man muss sich ja nur ein Byte zusammenbasteln (eben mit Carry-Schieberei), in dem jedes Bit 1 ist, wo dann ein längerer Puls ausgegeben werden soll.

dann setzt man einfach nen kompletten Port auf H, wartet die Zeit für den "0-Puls", gibt das Byte an den Port aus (also werden dann nach der Zeit alle Ausgänge L, die ein 0-Bit ausgeben sollen), wartet noch etwas (den Rest für den langen Puls halt), und setzt dann den kompletten Port auf L

Zitat von BadDeath

Ja, ich kann nun ohne Probleme alle 5 Pixel einzeln ansteuern.

dann muss aber der Reset "funktionieren", weil erst bei dem werden die Daten übernommen...

wegen dem Flackern: evtl. ist dann die Zeit zwischen 2 Pulsen doch zu kurz, dass er dann 2 kurze Pulse als einen langen interpretiert...? (z.B. weil die Flanken so arg "verschmieren", da müsste man das mal mit dem Oszi ansehen) - wobei Du eigentlich eh' schon ne "Extra-Wartezeit" hast, weil der ja in die Subroutine rein- und rausspringt, das braucht ja auch immer ein paar Takte...

mach' doch trotzdem mal zwischen die einzelnen Bits noch ne kurze Wartezeit, ob das was hilft - sehr nett wäre es, wenn Du auch mal ne längere (aber kürzer als Reset-Puls) machen könntest, mich würde das echt interessieren, ob die Vermutung stimmt, dass hauptsächlich die Länge des H-Pulses entscheidend ist, dann hätte man nämlich zwischen 2 Bits noch etwas Zeit für andere Sachen (wie eben z.B. nen kompletten Port zusammenbasteln, DMX empfangen o.ä.)

schön ist ja eigentlich, dass die Pulse nun nur halb so lang sein müssen, da man da ja wie gesagt (also während die Leitung H ist) nix anderes machen kann, und so dann weniger Takte vergeudet...

Teilen