Guten Abend Forum. Ich hoffe, hier kann mir jemand weiterhelfen. Ich programmiere momentan mit den Avr's rum (M8,M16...) Nun wollte ich fragen, ob es irgendwelche µC's gibt, die man auch in ASM programmieren kann, die aber mindestens doppelt oder dreimal so schnell wie die Avr's sind... so 50MhZ Ich steuere momentan 16 RGB Leds über mehrere Schieberegister an, mit dem Atmega 8 kein Problem(@ 16MhZ). Ich möchte aber das ganze auf 32 Rgb Leds ausbauen und da kommt mein zeitliches Problem.... der M8 ist fast nur mehr mit dem rausschieben der Bits beschäftigt. Die Software für das rausschieben der Bits ist sehr gut optimiert. Und irgendwie muß ich ja noch die neuen PWM Daten berechnen. Ich verwende dabei 256 Helligkeitsstufen, die ich auf keinen Fall verringern möchte. Multiplexen kommt für mich auch nicht in frage, da das ja auch keine Rechenzeit spart. Gibts da irgendetwas in einer normalen Preisklasse, was man in Asm programmieren kann? ARM oder sowas hab ich mal gehört... Oder gibts da was besseres? Wäre sehr dankbar für Eure Hilfe. David
Bist du sicher, dass die Software optimal ist ? Ich steuere ein LCD mit 384 Pixel mit 32 Stufen an oder auch 1280 LEDs mit 16 Graustufen. Beides mit einem mega8. Wenn ich das auf 256 Stufen hochrechne, dann sollten mindestens 70 LEDs mit 256 Stufen möglich sein. Beides mit Software die in C geschrieben ist. Soviel zu deiner sehr gut optimierten Software... Außer den SX Prozessoren fällt mir nicht wirklich viel ein. Vielleicht die Propeller uC mit mehreren Cores ?
Wenn 16 RGB derzeit kein Problem sind nimm zur Not 2 Mega8. Die Software ist dann schon fast fertig...
Hallo! Ich kann mir leider nicht ganz vorstellen, dass dein Vorhaben nicht mit einem Mega8 zu realisieren ist. Poste doch deinen ASM-Code, wenn du Hilfe willst, weil sonst ist es schwer nach zu vollziehen. Ausserdem benötigt der Atmega nur 2 Takte (oder wenn warens 4 -.-) für einen Schiebebefehl. Das sind rein rechnerisch 4 bzw 8 Millionen Schiebebefehle in der Sekunde o.O. Mfg thekilla
Muß es denn wirklich über ein Shift Register laufen? Wie währe es mit mehreren '373 + Adress Dekoder '138 das wäre 1x Out für die Adresse und ein 2. Out für die Daten von 8 LED's Also ADDR 0..11 Setzen auf PortA Daten D0..D7 Setzen auf PortB und noch einmal Strobe / wr und es sollte gehen. Was ich mir natürlich auch vorstellen könnte, allerdings noch nicht probiert habe einen Mega mit ext. RAM Funktion und die '138 + '373er + Adress/Data Latch an die RAM Schnittstelle und einfach den "RAM" beschreiben. Der mem_wr puls steuert den entsprechenden Treiber durch und gut ist. Somit währen vorausgesetzt die Daten liegen fertig vor gerade mal 12 Ram Schreibbefehle nötig. Der Rest geht von selbst. Muß natürlich noch mal alles überdacht werden aber von prinzip könnte es so gehen. Gruß, Tubie
Hi. Sorry, ich dachte, das die Software schon ganz gut ist. Habe sie leider auch nur aus diesem Forum geklaut. Die Grundstruktur von der Software stammt von Hagen. SPI ist in diesem Fall von Software geschrieben. Dazu habe ich 6 Stück 8 bit Schieberegister (4094). Jeweils 2 Stück sind immer für die Farben zuständig. Also 2 Stück geben nur das rot aus, die nächsten nur das grün und die letzten 2 nur das blau. Bei dieser Software SPI komme ich ca auf 300 Takte für die Berechnung der einzelnen Pixel und für die ausgabe an die Shiftregister. Ich hoffe, das Hagen da jetzt nichts dagegen hat, aber könnte man das besser machen? Software im Anhang David
siehst Du,
mit 12 8-Bit Treibern sind es:
12* out PortX 12 Cycles
12* out PortY 12 Cycles
12* inc addr 12 Cycles
12* sbi 24 Cycles
12* cbi 24 Cycles
-----------------------------
84 Cycles
für 32 RGB LED's. Vorausgesetzt du hast 12 Register noch offen, um die
Daten zu Puffern. Am besten ohne Schleife programmieren das spart
nochmal etwas.
Gruß,
Tubie
@David > nur mehr mit dem rausschieben der Bits beschäftigt. Die Software für das > rausschieben der Bits ist sehr gut optimiert. Und irgendwie muß ich ja Denkst du. > noch die neuen PWM Daten berechnen. Ich verwende dabei 256 > Helligkeitsstufen, die ich auf keinen Fall verringern möchte. > Multiplexen kommt für mich auch nicht in frage, da das ja auch keine > Rechenzeit spart. Meinst du? Irrtum. 32 RGB LEDs (=96 einzelne LEDs) kann man wunderbar mit 6 + 16 Pins ansteuern. 16 Pins schreit nach zwei normalen 8 Bit Ports, 6 Pins finden sich irgendwo auf nem anderen Port. Das Ganze ist mit 3 (DREI) OUT Befehlen komplett schaltbar, nix mit dutzend Bits durchklappen. Dabei schläft der AVR fast ein. > Gibts da irgendetwas in einer normalen Preisklasse, was man in Asm > programmieren kann? Wer nur einen Hammer hat, sieht überall nur Nägel. ;-) Anstatt den uC aufzubohren, sollte man den vorhandenen erstmal richtig nutzen lernen. > ARM oder sowas hab ich mal gehört... Oder gibts da was besseres? Ja, Brain 2.0 MFG Falk
Hallo Haben kürzlich auch eine Uhr aufbaut mit 4 mal 16RGB Leds. Die Ansteuerung wurde parallel ausgeführt (Einblenden im SRAM) und dauert so für alle LED's nur ca 25µs (AtMega128@16Mhz). Also: Lass die Schieberegister weg und gibs einfach parallel aus.... Gruß
Hi. Danke für die Zahlreichen antworten. @Falk >32 RGB LEDs (=96 einzelne LEDs) kann man wunderbar mit 6 + 16 Pins >ansteuern. 16 Pins schreit nach zwei normalen 8 Bit Ports, 6 Pins finden >sich irgendwo auf nem anderen Port. Das klingt eigentlich sehr gut. Verstehe ich das richtig, das man dann mit den 16 Pins die PWM Daten parallel an ein "latch"<--(stimmt das?) ausgibt und mit den anderen 6 Pins die latches ansteuert, welcher gerade die Daten annehmen soll. Was für eine Hardware würde ich da brauchen? Hat da schon jemand Erfahrung damit? Dann wäre also das ausgeben an die latches ein klax für den µC und ich müßte nur mehr die PWM Daten berechnen.
Hallo David. Ja das siehst du richtig. Du gibst einfach die 12 mal 8bits (=96) also 12Byte auf ein Latch aus. Du musst dir allerdings überlegen, ob du wie bei Falks Vorschlag: 2 Latches mit je 8bit verbaust, und die ausgabe über die (zusätzlichen) 6bits (drei würden auch reichen) dann gemultiplext ausgibst, hier musst du allerdings schneller ausgeben, weil dieses multiplexen ja noch "untergebracht" werden muss.. oder, ob du, wie ich es meinte 12latches verbaust, somit hättest du mit jeder Ausgabe (per interrupt??) nur 12Bytes zu lesen und zu speichern (24Befehle) Das kommt aber auf dein konkretes Porblem an.. Als Latch würde ich in jedem Fall den 74HC573 empfehlen.. Gruß
>Ich verwende dabei 256 Helligkeitsstufen Oder sind es doch nur 8? ;-) Da dem Helligkeitsempfinden von Augen eine logarithmische Charakteristik zu eigen ist [*], entspricht der Schritt von einer Helligkeitsstufe zur nächstniedrigeren einem Halb-so-lange-Einschalten der LED. 256 kannst Du genau 8 mal sukzessive halbieren, bis Du bei 1 angekommen bist. [*] Siehe sog. Weber-Fechner-Gesetz: "Die subjektive Stärke von Sinneseindrücken verhält sich logarithmisch zur objektiven Intensität des physikalischen Reizes." http://de.wikipedia.org/wiki/Weber-Fechner-Gesetz Deshalb sieht das richtige Schema, um eine LED zeitlich linear "helligkeits-gleichmäßig" hochzudimmen, so aus: LED aus LED für kurze Zeitspanne t mit "1/256"-PWM ansteuern LED für kurze Zeitspanne t mit "1/128"-PWM ansteuern LED für kurze Zeitspanne t mit "1/64"-PWM ansteuern LED für kurze Zeitspanne t mit "1/32"-PWM ansteuern LED für kurze Zeitspanne t mit "1/16"-PWM ansteuern LED für kurze Zeitspanne t mit "1/8"-PWM ansteuern LED für kurze Zeitspanne t mit "1/4"-PWM ansteuern LED für kurze Zeitspanne t mit "1/2"-PWM ansteuern LED mit Dauerstrom ansteuern Das sind acht Stufen zwischen "ganz aus" und "ganz ein". Machst Du es dagegen "falsch" mit (vermeintlichen) 256 Stufen so... LED für Zeit t mit "1/256"-PWM ansteuern LED für Zeit t mit "2/256"-PWM ansteuern LED für Zeit t mit "3/256"-PWM ansteuern LED für Zeit t mit "4/256"-PWM ansteuern LED für Zeit t mit "5/256"-PWM ansteuern ... LED für Zeit t mit "253/256"-PWM ansteuern LED für Zeit t mit "254/256"-PWM ansteuern LED für Zeit t mit "255/256"-PWM ansteuern LED mit Dauerstrom ansteuern ...wirst Du das Ergebnis eindeutig als nicht befriedigend empfinden, und zwar erscheint die LED dann als "komisch-zu-schnell-hell" (überzeuge Dich im Selbstversuch davon). Ein Unterschied von beispielsweise 238/256 und 239/256 der Zeit eingeschaltet lassen ist nämlich physiologisch praktisch nicht wahrnehmbar und entspricht deshalb nicht einer ganzen Helligkeitsstufe sondern nur einem kleinen Bruchteil davon.
@ AVRFan Kennst du eine Lösung um eine LED ohne 256 PWM Stufen mit 8 optisch korrekten Helligkeitsstufen anzusteuern ? @David Wiso verringerst du nach jeder LED den PWM Zähler.
@David > >32 RGB LEDs (=96 einzelne LEDs) kann man wunderbar mit 6 + 16 Pins > >ansteuern. 16 Pins schreit nach zwei normalen 8 Bit Ports, 6 Pins finden > >sich irgendwo auf nem anderen Port. > Das klingt eigentlich sehr gut. > Verstehe ich das richtig, das man dann mit den 16 Pins die PWM Daten > parallel an ein "latch"<--(stimmt das?) ausgibt und mit den anderen 6 > Pins die latches ansteuert, welcher gerade die Daten annehmen soll. Fast. > Was für eine Hardware würde ich da brauchen? Hat da schon jemand > Erfahrung damit? Du brauchst keine extra Latches. Dein AVR ist das Latch. Alles was du brauchst sind 16+6=22 NPN Transistoren, BC337 oder als SMD BC848. Plus ein paar Widerstände. > Dann wäre also das ausgeben an die latches ein klax für den µC und ich > müßte nur mehr die PWM Daten berechnen. Ja eben. Aber wie gesagt, du brauchst keine Latches, einfach auf den Port ausgeben und fertig. Nochmal nach dem Stichwort Multiplexen googlen und drüber nachdenken. @matthias > ob du, wie ich es meinte 12latches verbaust, somit hättest du mit jeder > Ausgabe (per interrupt??) nur 12Bytes zu lesen und zu speichern > (24Befehle) Das änder nixt an dem Bearbeitungsaufwand. Es steigert nur den Bauteilaufwand. Und der arme AVR langweilt sich nochmehr. > Das kommt aber auf dein konkretes Porblem an.. > Als Latch würde ich in jedem Fall den 74HC573 empfehlen.. Ich würde sie schlicht und einfach weglassen. MfG Falk
@ Benedikt K. > Kennst du eine Lösung um eine LED ohne 256 PWM Stufen mit 8 optisch > korrekten Helligkeitsstufen anzusteuern ? Ganz einfach, eine PWM mit 8 Stufen, nur dass die eben nichtlinear verteilt sind. Wie AVRFan das schon sehr deutlich dargestellt hat. MFG Falk
Wenn die PWM Stufen nicht linear verteilt sind, muss der uC aber totzdem schnell genug sein, um eigentlich alle linearen Stufen erzeugen zu können, sonst kann er die feinste Stufe nicht. Oder verstehe ich was falsch ?
> schnell genug sein, um eigentlich alle linearen Stufen erzeugen zu > können, sonst kann er die feinste Stufe nicht. Ja. Mfg Falk
Angehängte Dateien:
-
LED_MUX_6x16.png
40 KB
So, hier mal auf die Schnelle ein Designvorschlag für 32 RGB-LEDs, Common Anode. Die Standardbeschaltung für den AVR fehlt noch, dürfte aber nicht das Problem sein. MFG Falk
kurze Überschlagsrechnung: angenommene PWM-Frequenz: 100Hz -> 10ms Periodendauer angenommene 8Bit-PWM: 10ms/256 = 39us, d.h. die Schaltflanken können alle 39us kommen. Das ist die Zeit zwischen 2 Timerinterrupts. (z.B. bei 1/256-Ansteuerung). Das halte ich schon für reichlich knapp, wenn der uC noch anderes nebenher machen soll. Jetzt kommt noch dein Multiplex dazu. D.h. es kann maximal eine aus sechs LEDs "gleichzeitig" leuchten. Durch höheren Strom kannst du die verringerte Helligkeit (wg. kürzerer Ansteuerung) wieder ausgleichen - das zeitliche Problem bleibt aber. -> 39us/6 = 6,5us. Also wieder alle 6.5us müsste der Timerinterrupt kommen. Habe ich mich verrechnet oder kommt das so hin? Viel geht da nebenher aber nicht mehr, oder?!?
Ungeachtet der verschiedensten Lösungsvorschläge würde mich doch mal interessieren, ob konsumfreundliche Mikrocontroller für 50 MHz und mehr existieren.
Was ist für dich konsumfreundlich? Unabhängig davon ob diese Aufgabe hier nun sinnvoll gelöst ist oder nicht: für diesen Job wäre der Parallax-Propeller wahrscheinlich geeignet. Anonstens sind natürlich die ARMs passende Kandidaten. LPC2103 mit 70MHz und sehr schnellem Pinwackeln.
Die Schieberegister sind schon gut, aber man sollte sie am SPI port anhaengen und nicht bitbangen. Alternativ kann man ein Parallel zu SPI interface in einem CPLD bauen und das schieben dann mit dem CPLD machen. Ein schnellerer Prozessor macht wenig bis gar keinen Sinn. rene
Äh Moment: Schieberegister? Benutz das On-Board SPI Modul, dann brauchst du die sachen nicht herausschieben. Den SPI Bus kannst du mit max Fclk/2 laufen lassen.. Das ganze noch Interruptgesteuert und dein Mikrocontroller hat fast 100% seiner Rechenleistung für Kaffeekochen frei.
@ A.K.: Mhm das ist doch schonmal ganz nett. Konkretes Ziel von mir (mit dem Hintergrundgedanken, ob das überhaupt realisierbar ist) wäre eine Laufzeitmessung von Licht mit einer Genauigkeit von <1cm. Also zwei Stationen, die mit einer Auflösung von 1 ns und weniger einen Lichteinfall bemerken und protokollieren.
Hallo zusammen, @matthias: Da die Lcihtgeschwindigkeit für viele Anwendungen hinreichend genau bekannt ist, würde ich empfehlen, anstelle der Laufzeitmessung lieber den Zollstock rauszukramen und die Strecke abzumessen. Wenn es Dir auf genaue und genaueste Streckenmessung ankommt, dann probier das ganze per Ultraschall oder für die supergenaue Messung mit einem Interferrometer. Wäre dann nur noch die Frage, wie genau und welche Maximalwerte Du Messen willst (Die Länge Deines Autos muss nicht auf nm genau sein und die Dicke des Lacks wird kaum über den mm-Bereich gehen). Gruß Fred
@matthias Und wieso glaubt alle Welt, jeden Mist mit nem uC in Software machen zu müssen? Für solche Sachen gibt es zugeschnittene Hardware. MFG Falk
@ Richard > kurze Überschlagsrechnung: > angenommene PWM-Frequenz: 100Hz -> 10ms Periodendauer > sechs LEDs "gleichzeitig" leuchten. Durch höheren Strom kannst du die > verringerte Helligkeit (wg. kürzerer Ansteuerung) wieder ausgleichen - >das zeitliche Problem bleibt aber. -> 39us/6 = 6,5us. Also wieder alle >6.5us müsste der Timerinterrupt kommen. Richtig. Aber a) Bei 16 MHz sind das immerhin 104 Takte. Plenty of time. b) Wenn man sinnvollerweise die nichtlineare PWM von AVRFan mit 8 Stufen implementiert, dann ist spätestens nach der 2. oder 3. Stufe viiiiiel Zeit für den uC, andern Kram zu machen. c) Wer partou ne normale 8 Bit PWM machen will sollte darüber nachdenken, die PWM in einen CPLD zu verlagen und nur noch das MUXen im uC zu machen. Der hat dann aber wirklich nix mehr zu tun. Viele Wege führen nach ROM. Oder ins LED Land ;-) MFG Falk
> Und wieso glaubt alle Welt, jeden Mist mit nem uC in Software machen zu > müssen? Weil es meistens die günstigste, flexibelste und am leichtesten beschaffbare Lösung darstellt.
@ Fred: Würd ich gerne, ist aber nicht möglich. Ziel ist eine Blitzortung. Blitze senden elekromagnetische Strahlen aus, die auf einem bestimmten Frequenzband empfangbar sind. Diese breiten sich bekanntermaßen mit Lichtgeschwindigkeit aus. Ziel ist es jetzt, mit 3 bzw. 4 Messstationen im Abstand von einem Meter die Position des Blitzeinschlages herauszufinden. Aber ich möchte hier jetzt eigentlich nicht das Thema des Threads verändern, ich habe nur die Gunst der Stunde genutzt um in diesem Thread nach solchen schnellen Prozessoren zu fragen.
@matthias UNd du glaubst, dass diche ine 50 oder meinetwegen 100 MHz scheller PRozessor der Lösung des Problems näher bringt? Deine 1 meter entferneten Messtationen haben einen Laufzeitunterschied von knapp 3ns. Ausserdem sind die elektromagnetischen Impulse der Blitze irgendwo im Mittelwellenbereich angesiedelt, ich hab da so meine Zweifel, ob man da mit um 1m versetzten Messpunkten sinnvolle Ergebnisse bekommt. (Wellenlänge im Bereich mehrere Meter). @ Aufreger deluxe > > Und wieso glaubt alle Welt, jeden Mist mit nem uC in Software machen zu > > müssen? > Weil es meistens die günstigste, flexibelste und am leichtesten > beschaffbare Lösung darstellt. Jaja, die Generation Nintendo. Einen Horizont wie eine knieende Ameise und Scheuklappen noch dazu. Wo man früher nen Bimetall-Schalter zur Steuerung ner Kaffeemaschine eingebaut hat ist heute ein embedded Webserver drin. Und wenn der mit 20 MHz zu langsam ist, schreit man nach nem P4. Ist ja auch praktisch, da ist das Heizelement integriert. ;-) MFG Falk
Ich verstehe jetzt zwar den Zusammenhang zw. Bimetall-Schalter und PWM nicht, aber ist auch egal. Gehörst wohl auch zu der Generation, die, nur weil sie löten kann, der Meinung ist, voll die Peilung in Sachen Elektronik zu haben. Kommt hier neu ins Forum und will gleich mit den Großen pissen gehen... Kaffeemaschine und Webserver, hab ich noch nie gesehen. Bleibe bitte bei der Realität.
@ Aufreger deluxe > Ich verstehe jetzt zwar den Zusammenhang zw. Bimetall-Schalter und PWM > nicht, aber ist auch egal. Gehörst wohl auch zu der Generation, die, nur Es ging auch nicht um PWM, sondern den mal wieder vollkommen verkrampften Versuch, jegliche Dinge mittels (schnellem) uC zu lösen. > weil sie löten kann, der Meinung ist, voll die Peilung in Sachen > Elektronik zu haben. Kommt hier neu ins Forum und will gleich mit den Keine Bange, ich hab schon ein klein wenig mehr Ahnung von Elektronik, als nur zu wissen welches Ende vom Lötkolben man anfassen sollte . . .;-) > Großen pissen gehen... Meiner ist trotzdem länger . . . > Kaffeemaschine und Webserver, hab ich noch nie gesehen. Bleibe bitte bei > der Realität. Tu ich. Dir sagen der Begriff Ironie und Satire etwas? Ausserdem, du hast das übersehen. ;-) MFG Falk
Und ich hab den grössten! 23 cm, kein Witz! Also regt euch ab Jungs und geht wieder spielen.
Hi Hätte da noch ein paar fragen. @Falk Dein Schaltplan sieht echt gut aus. 1. Muß ich da nicht noch Widerstände vor den leds verbauen, oder kann man da was mit dem IRF machen? 2. Wenn ja, kann ich da kleinere Widerstände nehmen, da sie ja nur mit 1/6 gepulst werden. 20m mA x 6 = 120 mA. Überleben das die Leds? 3. Wo kann ich in Eagle den IRF7341 finden? @AVRFan Ich habe 2 Methoden versucht. erstens meine: LED für Zeit t mit "1/256"-PWM ansteuern LED für Zeit t mit "2/256"-PWM ansteuern LED für Zeit t mit "3/256"-PWM ansteuern LED für Zeit t mit "4/256"-PWM ansteuern LED für Zeit t mit "5/256"-PWM ansteuern ... LED für Zeit t mit "253/256"-PWM ansteuern LED für Zeit t mit "254/256"-PWM ansteuern LED für Zeit t mit "255/256"-PWM ansteuern LED mit Dauerstrom ansteuern Hab Dabei ein pwm Register von 0 auf 255 raufgezählt und wieder runter. Die Led dimmt schön ein und aus. Und bei Deiner Version: LED aus LED für kurze Zeitspanne t mit "1/256"-PWM ansteuern LED für kurze Zeitspanne t mit "1/128"-PWM ansteuern LED für kurze Zeitspanne t mit "1/64"-PWM ansteuern LED für kurze Zeitspanne t mit "1/32"-PWM ansteuern LED für kurze Zeitspanne t mit "1/16"-PWM ansteuern LED für kurze Zeitspanne t mit "1/8"-PWM ansteuern LED für kurze Zeitspanne t mit "1/4"-PWM ansteuern LED für kurze Zeitspanne t mit "1/2"-PWM ansteuern LED mit Dauerstrom ansteuern Wenn ich so eine Led ein und ausdimmen lasse, dann sieht das ganze sehr ruckelig aus. Also sie dimmt nicht schön ein sondern es schaut beim eindimmen so abgehackt aus, da es ja nur 8 verschiedene Helligkeiten sind. Oder hab ich da was falsch verstanden? Gruß David
@ David > 1. Muß ich da nicht noch Widerstände vor den leds verbauen, oder kann > man da was mit dem IRF machen? Wozu? Die 16 Transistoren T7..T22 sind, man schaue in den Schaltplan, Konstantstromquellen. Da braucht es keine weiteren Widerstände. > 2. Wenn ja, kann ich da kleinere Widerstände nehmen, da sie ja nur mit > 1/6 gepulst werden. 20m mA x 6 = 120 mA. Überleben das die Leds? Wenn die MUX immer muxt und nicht stehen bleibt, JA. > 3. Wo kann ich in Eagle den IRF7341 finden? AFAIK gar nicht. Selber machen ist angesagt. SO-8 Gehäuse und P-Kanal Mosfet Symbol. MFG Falk
Hallo Falk. Das sind also Konstantstromquellen. Also lassen die immer nur 130mA durch? Und wie ist das mit den Volt? Die roten Leds benötigen ja nur 2V und die blauen und grünen benötigen 3,6V. Steuert das der BCP von selbst? Achja, beim Multiplexen.. Wenn ich die Leds mit 100Hz ansteuern will, dann muss ich so rechnen...stimmt das? 100Hz x 256 Helligkeiten x 6 Multiplexen = 153600 Hz Also müßte man dann bei 16MhZ alle 104 Takte die Leds ansteuern. Stimmt das so? Gruß David
Ich weiß nicht, ob hier Stromquellen notwendig sind, du hast doch ne feste SPannung von 5Volt, da kannst du doch jede Farbe auf einen Multiplexer nehmen und die Vorwiderstände exakt ausrechnen. Und nimm die "oberen" Transistoren NPN Typen in Kollektorschaltung, da sparst du dir die Basiswiderstände... Entscheidend für die Hardware ist aber auch die Organisation des Videospeichers.. evtl so: uint8_t rot[4] ; uint8_t grün[4]; uint8_t blau [4]; somit ist jedem Bit eine Farbe einer LED zugeordnet. rot[0]: bit0..7 gleich LED1..8 rot, rot[1]: bit0..7 gleich LED9..16 rot, .. Hier ein beispiel: siehe anhang
Hallo Mathias. Naja, bei Deiner Schaltung brauch ich wieder 96 Stück Widerstände, darum würde ich die Variante von Falk bevorzugen. Aber nochmal zu vorherigen Frage: >100Hz x 256 Helligkeiten x 6 Multiplexen = 153600 Hz >Also müßte man dann bei 16MhZ alle 104 Takte die Leds ansteuern. Stimmt >das so? Kann mir das jemand beantworten?
@ David > Das sind also Konstantstromquellen. Also lassen die immer nur 130mA > durch? Genau, Nomen est Omen. > Und wie ist das mit den Volt? Die roten Leds benötigen ja nur 2V und die > blauen und grünen benötigen 3,6V. Steuert das der BCP von selbst? Das ist ja der Trick der Konstantstromquelle! > Wenn ich die Leds mit 100Hz ansteuern will, dann muss ich so > rechnen...stimmt das? > 100Hz x 256 Helligkeiten x 6 Multiplexen = 153600 Hz > Also müßte man dann bei 16MhZ alle 104 Takte die Leds ansteuern. Stimmt > das so? Ja, stimmt. Ist ja auch schondreimal vorgerechnet wurden im Thread ;-) MFG Falk
@ Matthias > Ich weiß nicht, ob hier Stromquellen notwendig sind, du hast doch ne > feste SPannung von 5Volt, da kannst du doch jede Farbe auf einen > Multiplexer nehmen und die Vorwiderstände exakt ausrechnen. Und nimm die Das glaube ich kaum, denn sowohl durch die Matrixsteuerung als auch die Common Kathode/Anode Beschaltung der üblichen RGB-LEDs ist es Essig mit separaten Vorwiderständen für R/G/B. Ausserdem ist dir hoffentlich bekannt, dass die Flusspannung der LEDs a) mit der Temperatur als auch b) mit der Herstellungscharge schwankt?! Wo ist das Problem mit den Stromquellen? Ausserdem, deine Schaltung ist ein wenig komisch. Du brauchst für 3 RGB LEDs (=9 Einzel-LEDs) 3+3 Transistoren + 9 Widerstände + 3 Pins? Macht bei 32 RGB-LEDs (und das war ja die Aufgabenstellung) 32/3 = 11 11 * 6 = 66 Transistoren 11 * 9 = 99 Widerstände 11 * 3 = 33 Pins für die RGB Ansteuerung So ne richtige Matrix ist das aber nicht, vor allem sehe ich nicht ganz den Multiplex-Faktor? > Entscheidend für die Hardware ist aber auch die Organisation des > Videospeichers.. Erstmal ne gescheite LED-Matrix, dann die Software. MfG Falk
@ Matthias Ach ja, auch auf die Gafahr hin mich zum hundertsten Mal zu wiederholen. Schaltpläne als GIF oder PNG speichern! Und wenn mans auf Teufel komm raus in PDF umwandeln will, dann dort bitte als verlustfrei komprimierte Bild einblenden. Ja, gescheiten PDF-Generatoren kann man das sagen. MFG Falk
Also: pdf ging schneller als irgendein Bild. @Falk: Der Multiplexfaktor ist da, man muss ihn nur finden.. Ihr könnt gern die LED's irgendwie an irgendwelche WAHLLOSEN Ports anklemmen, und die Multiplexleitungen auch gerne irgendwelche beliegigen PINS verwenden.. Ihr werdet euch dann "freuen" wenn ihr dann sinnvolle Ausgaben (Zeichensätze..oder so, weiß ja den Zweck nicht) programmieren wollt und jedes Bit (für jede Farbe) an irgendwelche wahllosen Stellen kopieren dürft... Deshalb heißt es bei mir nicht zwingend: soviel Funktionalität wie möglich in die Software packen, sondern auch mal etwas in Hardware aufbauen. Damit nicht sinnlos Klimmzüge in der SOftware gemacht werden müssen. Wir haben kürzlich 64RGB-Leds (LATB T66C) mit klassischen Vorwiderständen verwendet und können keine Unterschiede in der Helligkeit feststellen.. Aber das ist ja ein Forum zum Meinungsaustausch, habe ja nur meine Erfahrungen hier zum Besten gegeben.. Diese können von anderen verwendet oder verworfen werden.. Ich fahre mit diesem Konzept ziemlich gut, aber andere können gern meine Erfahrungen nachholen.. Gruß
Angehängte Dateien:
-
S-RAM.JPG
43 KB
Habe jetzt mal versucht, die Software zu schreiben, für den Schaltplan was Falk gezeichnet hat. Also ich lege meine PWM Daten im S-Ram ab. Dabei ist: 0x0060 die 1'te rote Led 0x0061 die 1'te grüne Led 0x0062 die 1'te blaue Led 0x0063 die 2'te rote Led 0x0064 die 2'te grüne Led ... ... ... 0x00be die 32'te grüne Led 0x00bf die 32'te blaue Led Ich finde, daß man so am einfachsten die Bits manipulieren kann. Im Multiplexbetrieb gebe ich dann die pwm Daten folgender Maßen aus: ld temp1,x cp pwm, temp1 adc temp2,temp2 adiw xh:xl,6 als erstes hole ich mir das erste byte von 0x0060 dann vergleich ich es mit meinem pwm Register falls das carrybit gesetzt ist, schiebt er es in temp2 dann noch zu 0x0060 6 dazuaddieren, damit ich zur nächsten roten Led komme In meinem Timer muß ich dann die 4 oberen Befehle 16mal durchlaufen lassen. Ich verwende dazu keine Schleife, das spart mir ein paar Takte. Ganz zum Schluß lade ich mir noch von 0x00c0 bis 0x00c5 die Daten für den IRF und gib dann alle 3 bytes auf den jeweiligen Port aus. Bild im Anhang. Nun meine Frage. Könnte man das noch irgendwie schneller oder besser machen, oder kann man das so lassen? @ Falk Also den BCP und den IRF hab ich bei Reichelt gefunden. Laut Datenblatt brauch ich ja dann nur 2 IRF, weil in einem 2 Transistoren verbaut sind. Bei den BCP52 werd ich aus dem Datenblatt nicht schlau. Liefert der immer 130mA oder kann man das mit den Vorwiderständen regeln? Es könnte nämlich sein, das ich vielleich mal mehrere Leds verbaue. Wie kann ich dann die mA verändern. Gruß David
Moin Moin Bin nach der Silvesterfeier wieder ansprechbar ;-) @ Matthias > Also: pdf ging schneller als irgendein Bild. Eagle kann direkt PNG exportieren. > @Falk: > Der Multiplexfaktor ist da, man muss ihn nur finden.. Suchet, so werdet ihr finden. Ich habs immer noch nicht so ganz kapiert. Wie MUXt du denn deine LEDs nun? > Ihr könnt gern die LED's irgendwie an irgendwelche WAHLLOSEN Ports > anklemmen, und die Multiplexleitungen auch gerne irgendwelche beliegigen > PINS verwenden.. > Ihr werdet euch dann "freuen" wenn ihr dann sinnvolle Ausgaben > (Zeichensätze..oder so, weiß ja den Zweck nicht) programmieren wollt und > jedes Bit (für jede Farbe) an irgendwelche wahllosen Stellen kopieren > dürft... Auch wenn du damit im Prinzip Recht hast, darfst du davon ausgehen, dass auch andere Leute einschliesslich mir darüber nachgedacht haben. > Deshalb heißt es bei mir nicht zwingend: soviel Funktionalität wie > möglich in die Software packen, sondern auch mal etwas in Hardware > aufbauen. Damit nicht sinnlos Klimmzüge in der SOftware gemacht werden > müssen. Das hat niemand behauptet oder vorgeschlagen. > Wir haben kürzlich 64RGB-Leds (LATB T66C) mit klassischen > Vorwiderständen verwendet und können keine Unterschiede in der > Helligkeit feststellen.. Unterschied zu was? Na klar geht es auch mit normalen Vorwiderständen, aber eben mit höherem Bauteilaufwand und ggf. kleineren funktionalen Einschänkungen. > Aber das ist ja ein Forum zum Meinungsaustausch, habe ja nur meine > Erfahrungen hier zum Besten gegeben.. Diese können von anderen verwendet > oder verworfen werden.. Ich fahre mit diesem Konzept ziemlich gut, aber > andere können gern meine Erfahrungen nachholen.. Ja. Aber es darf dann doch bitte auch über Vor- und Nachteile von Lösungen gesprochen werden bzw. sachlich Kritik geübt werden. @ David > Im Multiplexbetrieb gebe ich dann die pwm Daten folgender Maßen aus: > Ganz zum Schluß lade ich mir noch von 0x00c0 bis 0x00c5 die Daten für > den IRF und gib dann alle 3 bytes auf den jeweiligen Port aus. > Nun meine Frage. Könnte man das noch irgendwie schneller oder besser > machen, oder kann man das so lassen? Naja, die Frage ist, ob man die PWM-Daten ständig online berechen will oder nur einmal und diese dann im SRAM einfach ablegt und per Timer einfach ausgibt. Die MEGAs haben ja ne Menge SRAM, und wenn man die nichtlineare PWM von AVRFan implementiert, hält sich der Speicherbedarf auch in Grenzen (8x6x2 = 96 Bytes) > Also den BCP und den IRF hab ich bei Reichelt gefunden. Das war Absicht. ;-) > Laut Datenblatt brauch ich ja dann nur 2 IRF, weil in einem 2 > Transistoren verbaut sind. Du brachst drei, wenn du 16x6 MUXen willst. > Bei den BCP52 werd ich aus dem Datenblatt nicht schlau. > Liefert der immer 130mA oder kann man das mit den Vorwiderständen > regeln? > Wie kann ich dann die mA verändern. Die drei Widerstände bestimmen den Strom. Wenn du den ändern willst, musst du im wesentlichen nur den 2,2 Ohm Widerstand ändern. Am bestem mit Pspice aufbauen und simulieren, hab ich auch gemacht. MFG Falk
>Liefert der immer 130mA oder kann man das mit den Vorwiderständen >regeln? Der liefert nur dann 130mA, wenn er auch Konstantstromquelle beschaltet ist, so wie in diesem Fall.
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.