USB RGB-LED Projekt

[R4z0r1989]

So leute jetzt hat mich das Lötfieber gepackt,
zwar ned ganz so schlimm wie die schweinegrippe aber es macht mich nächtelang wach

ich habe folgendes vor und hoffe dass ich von euch ansätze, hilfe und vll nen schaltplan bekomm

ich will eine stehende usb verbindung zu meiner (noch nicht vorhandenen) platine, diese verarbeitet mein protokoll was ich ihr vom pc aus geben würde, und diese steuert dann ca. 16 parallel (und alle in der selben farbe leuchtende) RGB-LEDs.

das ganze soll nur leuchten wenn der PC an ist und sollte falls möglich mit der vom usb gegebenen internen 5 volt spannung laufen.

vielen dank im voraus und das meine lötsucht ned verdampft

[STARGÅTE]

ich hatte vor n Monat oder so, auch Lötfieber und habe mir über das COM-Port ein 8er-Lauflicht gebaut.

Gute Tips dazu gabs bei Google, PB an sich hilft dir ja bei der Platine recht wenig ^^

Stichworte : LED+Cube, Lauflicht

Es ist jedoch meist so das man den Port nur zur Steuerung nutzt und die Stromversorgung von außen kommt.
Vorallem hängt es vom LED Typ ab, ob der, mit der ehr geringen Stromstärke aus dem USB Port, überhaupt leuchtet.

[R4z0r1989]

hey stargate danke für deine antwort aber ich will eig. weniger ein lauflicht sondern eher individuell einstellbare farben durch die rgb's

sprich rot(0-255) grün(0-255) blau(0-255)

hoffe dass ich hier trotz dass es wenig mit pb zu tun hat weitere hilfe bekomm

[Crawler]

Das sollte so schwer nicht sein. Man nehme einen netten Mikroprozessor (bspw. einen Tiny von Atmel) und schließe ihn über die serielle Schnittstelle an den PC. Serielle Schnittstelle? Ja! Da kann man ganz wunderbar einen USB-Seriell-Umwandler (gibts bei reichelt.de für 'nen schmalen 5er) anschließen. Aletrnativ kann man das USB-gedöns auch auf den µC packen, im Anfängerforum gibts aktuell einen Thread, in dem ein so beschriebener µC über eine dll angesprochen wird.
Nun zur Programmierung des µC: Weil wir hier in einem Basic-Forum sind, schlage ich mal die kostenlose Version von Bascom vor. Mit der schafft man mühelos eine Software-PWM mit drei Kanälen, nämlich für Rot-, Grün- und Blaukanal. Da der Ausgangspin des µC die LEDs nicht direkt treiben kann, sollte man mittels Transistoren/Mosfets die Ausgänge verstärken. Dann überlegt man sich noch ein Übertragungsprotokoll, beispielsweise überträgt man bei jeder Änderung der Farbe ein "RxxxGxxxBxxx", nach dem der µC die Farbe über das Pulse/Pause-Verhältnis anzeigt.
Das entsprechende PureBasic-programm kümmert sich nur noch um die gewünschte Farbe, beispielsweise kann man mit bestimmten Farben auf Ereignisse wie Maileingang etc. reagieren oder einfach lustige Farbwechselspiele kreieren.

[Crawler]

Nun hat mich doch die Lust gepackt, das ganze mal umzusetzen. PC-seitig wird dieser Code zum Testen laufen:

Code: Alles auswählen

Enumeration
  #MainWindow
  #BTN_Quit
  #BTN_Connect
  #BTN_Disconnect
  #TB_Red
  #TB_Green
  #TB_Blue
  #STR_Output
  #Port
  #CB_Port
EndEnumeration

Procedure Ausgabe (r, g, b, c)
  Output.s = "R"+RSet(Str(r), 3, "0")+"G"+RSet(Str(g), 3, "0")+"B"+RSet(Str(b), 3, "0")+"E"
  SetGadgetText (#STR_Output, Output)
  If StartDrawing (WindowOutput (#MainWindow))
    Box (130, 20, 80, 80, RGB(r, g, b))
    StopDrawing ()
  EndIf
  If c=1 
    WriteSerialPortString (#Port, Output)
  EndIf   
EndProcedure

ProgramName.s = "RGB-Control"
OpenWindow (#MainWindow, #PB_Any, PB_Any, 230, 300, ProgramName.s)
ButtonGadget (#BTN_Quit, 120, 270, 100, 20, "Ende")
ButtonGadget (#BTN_Connect, 120, 200, 100, 20, "Verbinden")
ButtonGadget (#BTN_Disconnect, 120, 225, 100, 20, "Trennen")
DisableGadget (#BTN_Disconnect, 1)
TrackBarGadget (#TB_Red,   20, 10, 20, 255, 0, 255, #PB_TrackBar_Vertical)
TrackBarGadget (#TB_Green, 50, 10, 20, 255, 0, 255, #PB_TrackBar_Vertical)
TrackBarGadget (#TB_Blue,  80, 10, 20, 255, 0, 255, #PB_TrackBar_Vertical)
StringGadget (#STR_Output, 10, 270, 100, 20, "")
ComboBoxGadget(#CB_Port, 120, 175, 100, 20)
For i = 1 To 20 
  If OpenSerialPort (#Port, "COM"+Str(i), 9600, #PB_SerialPort_NoParity, 8, 1, #PB_SerialPort_NoHandshake, 64, 64) 
    AddGadgetItem(#CB_Port, -1,"COM" + Str(i))
    CloseSerialPort (#Port)
  EndIf  
Next 
SetGadgetState (#CB_Port, 0)         ; Voreinstellung für seriellen Port


Repeat  
  Event = WaitWindowEvent (10) 
  
  If Event = #PB_Event_CloseWindow
    Quit = 1
  EndIf
  
  If Event = #PB_Event_Gadget
    Select EventGadget() 
      Case #BTN_Quit
        Quit=1
      Case #BTN_Connect
        If OpenSerialPort (#Port, GetGadgetText (#CB_Port), 9600, #PB_SerialPort_NoParity, 8, 1, #PB_SerialPort_NoHandshake, 64, 64) 
          connect = 1
          DisableGadget (#BTN_Connect, 1)
          DisableGadget (#CB_Port, 1)
          DisableGadget (#BTN_Disconnect, 0)  
        EndIf
      Case #BTN_Disconnect
        connect = 0
        DisableGadget (#BTN_Connect, 0)
        DisableGadget (#CB_Port, 0)
        DisableGadget (#BTN_Disconnect, 1)
        CloseSerialPort (#Port)  
      Case #TB_Red
        ValueRed=GetGadgetState (#TB_Red)
      Case #TB_Green
        ValueGreen=GetGadgetState (#TB_Green)
      Case #TB_Blue
        ValueBlue=GetGadgetState (#TB_Blue)      
    EndSelect    
  EndIf      
  
  Ausgabe (ValueRed, ValueGreen, ValueBlue, Connect)
  
Until Quit

Bei Fragen, Meinungen und Anregungen bitte hier posten!

MfG Crawler

[WPö]

Hallo, Razor!

Das ist eine typische Mikrokontrollerschaltung, was Du da willst. Zum Glück bin ich Mikrokontrollersystementwickler und mache das seit Jahren.

1. Bedarfsanalyse: 16 RGB-LEDs per µC in allen Farben und Helligkeiten steuern können, µC-Ansteuerung per USB oder RS232 durch den PC.

2. Analyse: Da RGB-LEDs je nach Typ vier oder sechs Anschlüsse haben und eine oder zwei gemeinsame Anoden oder Kathoden, mußt Du die LEDs mitsamt Vorwiderständen parallelschalten. Da ich jetzt zuwenige Informationen von Dir habe, gehe ich einfach mal von 5V Betriebsspannung und gemeinsamer Kathode der LEDs aus. Diese zusammengefaßten Anoden bestromst Du dann mit einem P-Kanal-MOSFET, dessen Ansteuerung digital per PWM direkt vom µC kommt.
Da drei Farben zu regeln sind, brauchst Du auch drei voneinander unabhängige PWM-Ausgänge. Hier bieten sich die Atmel an, die ich für solche kleinen Sachen gerne verwende. Da Du 256 Stufen jeder Farbe regeln willst und kein Geflacker brauchen kannst, berechnest Du jetzt die Zählerbetaktung: 25Hz unterste Grenze für die Wiederholrate mal 256 Stufen = 6,4kHz. Solche µC schaffen locker das Hunderfache, also warum nicht? Wir wählen eine Zählertaktung von ca. 1MHz, der µC braucht dann 1/2/4/8/16MHz. Da wir keine hochgenaue Taktung brauchen, schenken wir uns den Quarz und nehmen einen internen RC-Oszillator, der auf einer der o.g. Frequenzen arbeitet. Gewählt wird irgendein Mega, z.B. ATmega48-20PU (hier in der DIL-Bauform, da ich einfach mal annehme, daß Du über keine SMD-Löterfahrung verfügst). Der µC muß zu den drei PWM-Ausgängen auch noch einen RS232-Anschluß haben. Das ist bei allen Atmels der Fall.

3. Synthese: Ein ATmega48-20PU auf STK500, drei MOSFETs vom Typ IRF9510, 48 Vorwiderstände (an die If der LEDs angepaßt) und 16 LEDs vom Typ Kingbright LF5WAEMBGMBW o.ä.. Jetzt kommt noch der RS232-USB-Wandler FT232BL (für Dich leider in TQFP-32-Gehäuse) mit entsprechender äußerer Beschaltung, s. Datenblatt. Zum Schluß brauchen wir noch eine Stromversorgung mit 5V und ca. 1A. Die Versorgung kann nicht aus dem USB-Anschluß erfolgen, da dieser bei 500mA abdankt und die ausgegebene Spannung laut USB-Definition ab 3,4V betragen darf - die blauen LEDs würden dann gar nicht mehr leuchten.

4. Firmware: Die gestaltet sich zum Glück recht einfach: Einstellung auf int. Taktung mit 8MHz, alle Anschlüsse auf Eingänge mit Pull-up schalten, die drei Zeitgeber initialisieren auf 1MHz Taktung, Teilung durch 256, negierte Ausgabe. RS232 initialisieren, dann Eintritt in die Hauptschleife. Dort nur noch das zurechtgebastelte Protokoll auswerten und die neuen Daten in die Zeitgeberregister schreiben. Fertig.

5. Anmerkungen: Ich empfehle, einen separaten RS232-USB-Wandler zu verwenden, den Du übrigens auch für die Programmierung des µC im STK500 brauchst. Das spart einiges an Lötarbeit, obwohl Du dann noch einen Pegelkonverter brauchst, etwa einen MAX232. Alternativ kannst Du auch den Datenverkehr parallel abwickeln. Dann brauchst Du nur einen anderen USB-Wandler, FT245BL und hast auch keine Probleme mit der Anpassung des RS232-Taktes. Dafür allerdings benötigst Du 12 Leitungen am µC, die der ATmega48-20PU aber hat. Dies ist der von mir generell verwendete Anschluß von USB an einen ATmega, da ich hauptsächlich mit wesentlich schnelleren Steuerungen zu tun habe.

Noch Fragen, Kienzle?

Grüße - WPo

[Crawler]

Sehr ausführlich beschrieben, so hätte ich das auch gemacht. Leider ist dieses Projekt bei mir etwas ins Stocken geraten. Mein Seriell-USB-Adapter verweigert seinen Dienst unter Win7 64bit...

[WPö]

Mein Seriell-USB-Adapter verweigert seinen Dienst unter Win7 64bit...

Ja, die billigen Dinger leiden an meist sehr schlechter Treiberunterstützung. Sogar mit Linux hat man da öfters Probleme.
Windoof 7 ist recht neu. 64-Bit-Unterstützung ist auch nicht gerade vordringlich für die Billigwandler-Hersteller. Vielleicht auf die Herstellerseite gehen und mal nachsehen/nachfragen, ob es neue Treiber gibt? Sonst noch beim Händler anfragen. Wenn der Kundenbindung und Kundendienst großschreibt, wird er Dir weiterhelfen wollen. Ob er kann, ist wieder ein anderes Paar Stiefel.

Gruß - WPo

[Crawler]

Ein neuer USB-Seriell-Wandler hat seinen Dienst aufgenommen, ich hoffe, dass es mit dem Projekt bald weitergeht.
Falls es jemanden interessiert: Ein Delock 61460 funktioniert unter Win7 64bit prima, der ist mit einem FT232-Chip ausgestattet. Die verbaute blaue LED nervt zwar etwas, aber darüber werde ich mal hinwegsehen.
Guten Rutsch euch allen!

[WPö]

Heißen Dank, Crawler!

Mit dem neuen Konverter haste dann auch wieder Zugriff auf ein STK500 oder was auch immer Du benutzt. Die LED nervt? Schwarzes Klebeband nehmen! An meinem Multimedia-PC reichte ein aufgemaltes Gitter mit 'nem CD-Markierer auf der Blende.
Um das Projekt sinnvoll weiterzubearbeiten, sollte sich R4z0r1989 mal wieder melden. Seine Netzpräsenz ist nicht erreichbar. Urlaub?

Die Firmware dazu würde ich entweder in C oder Asm schreiben. Die dürfte so einfach sein, daß Asm nichts ausmacht. Es ist ja auch meine bevorzugte Sprache. Basic ist zwar im Prinzip möglich, aber (aus meiner Sicht) zuviel Aufwand für fast keinen Effekt.

Naja, mal sehen, wie's weitergeht...

Gruß - WPo