Beiträge von maveric00

Hallo,

beide Zollkategorien sollten 0% haben, insofern sollten "nur" die 19% anfallen. Der Streifen wird mit 24V gespeist, hat 19 Watt/Meter bei min 1200 Lumen/Meter. Allerdings momentan noch nicht ganz klar, ob CRI 85 oder CRI 90 - da hat sich Ivan noch nicht so klar ausgedrückt (er hat einmal von >90 und einmal von >85 gesprochen). Und da Sonderanfertigung ist mit einer "länger als normalen" Lieferzeit zu rechnen, damit mach das Zusammenlegen mit Deiner Bestellung auch keinen Sinn, oder?

Schöne Grüße,
Martin

Hallo,

naja, auf den Warenwert (und das ist für den Zoll der Warenpreis + Versand) kommen noch 19% Einfuhrumsatzsteuer und entweder mit der TARIC-Nummer 9405 40 10
(Other Lamps, searchlight and spotlight) bzw. besser 8541401000 (LEDs, auch zu Modulen verbaut, aber noch keine fertigen Lampen) 0% Zoll 'drauf.

Ich hab' übrigens jetzt auch für etwas ganz anderes dort angefragt, nämlich einen 3528-Streifen mit 240 LEDs/Meter (für eine Endlighten-Anwendung), Warm-Weiss mit CRI>90; erste Preisindikation wären $7,70 pro Meter. Hätte da noch jemand Interess 'dran?

Schöne Grüße,
Martin

2. Edit: Ach ja, bei 100 m braucht man sich über die Freigrenzen keine Gedanken zu machen, die liegen so bei 22 Euro Warenwert für Umsatzsteuer bzw. 5 (oder 10?) Euro Zoll...

Hallo,

überschlägig reden wir bei 22 Streifen a 54 LEDs bei vollem Weiss von rund 415 Watt bzw. 83 Ampere. Sicher, dass das das Netzteil/die Endstufe ausgehalten hat? Ansonsten könnte es zu einer Überspannung gekommen sein, die dann Deine LEDs zerstört hat. Oder aber irgendwo hat sich die Zuleitung gelöst (z.B. zwischen dem 1. und 3. Streifen) und der ganze Strom ging durch die Streifen, wodurch die Leiterbahnen zerstört wurden. Bei den Stromstärken braucht es schon ziemlich dicke Kabel. So würde sich z.B. ein 1mm^2-Kabel auf über 300°C erwärmen und sich dadurch selbst auslöten...

Schöne Grüße,
Martin

Hallo,

oder - an Stelle eines AVRs in Kombination mit WiFi-Modul: eines der beiden Carambola Boards. Ist ein kompletter Linux-Rechner mit Ethernet/WiFi/USB/UART/SPI/GPIO (und anderes), also ähnlich wie ein RPI, mit max. 1.5 Watt Stromaufnahme (das RN-171 kommt bei TX auf 0.7 Watt). Wie die Aufnahme im Normalbetrieb ist, kann ich aktuell nicht genau sagen, es gibt aber Berichte, die von 0.8 bis 1.0 Watt sprechen . Preislich auch ganz in Ordnung (ein Modul 19€ oder 22€, runter bis 15€ bei Abnahme von 100 Stück).

Schöne Grüße,
Martin

Hallo,

wenn es mit dem anderen Wert auch nicht funktioniert (10011111), dann wäre mein nächster Schritt, mit zwei Low Current LEDs (+ Vorwiderstände, dann reicht allerdings der integrierte Pullup für SDA nicht mehr aus, und es muss ein externer Pullup in Größe von ~2-4 kOhm eingeplant werden) oder (etwas schwieriger, da der Takt bei nur einem Messgerät nicht sichtbar ist) mit einem Multimeter oder einem Oszilloskop SCL und SDA (bzw. nur SDA) anzusehen, ob die Bitfolge dem Datenblatt entspricht (möglichst direkt am LM75). Dazu kann man die delay definitionen alle auf _delay_ms(1000) setzen, dann wird das schön langsam herausgetaktet. Hab' ich mal so gemacht, als ich eine I2C-Routine entwickelt habe, die 8 I2C-Busse gleichzeitig bedienen konnte. Der Source davon nützt Dir allerdings nicht wirklich etwas, da ich bisher auch keinen Fehler in den verlinkten Routinen entdeckt habe.

Alternativ kann man auch zwei LEDs mit Vorwiderständen an zwei andere Ausgänge hängen, die SDA und SCL-Definitionen entsprechend anpassen und dann zumindest die Daten des Masters überprüfen (der Slave, da nicht vorhanden, liefert dann immer eine 1 zurück). Allerdings fließt dann bei SDA nur zwischen 0.1 und 0.3 mA, was eventuell etwas wenig ist, um eine LED zum leuchten zu bringen. Auch hier kann dann ein externer Pullup in der Größenordnung 300-500 Ohm helfen (bei "normalen" LEDs, die werden dann zwar mit deutlich unter 20 mA betrieben, dafür grillt man den AVR aber auch nicht) .

Wird aber beides sehr eng bis morgen, über das Wochenende könnte es aber klappen (wenn Du entweder Multimeter oder LEDs und Widerstände hast).

Da ich weder die Hardware habe, noch die myAVR-Seite aktuell die Dokumente 'rausrückt, kann ich nicht mehr viel weiter raten. Ich drücke aber beide Daumen...

Schöne Grüße,
Martin

Hallo,

noch was vergessen... Diese Sequenz:

#define I2C_DDR			DDRC					// Register für die I2C Kommunikation
#define I2C_DDR_REG_BIT	DDC7					//
#define I2C_PORT		PORTC					// I2C Port definition


#define SCL				PC6						// Port B Pin 1
#define SDA				PC7						// Port B Pin 2

muss an das myAVR-Board angepasst werden, je nachdem an welchem Pin SCL und SDA hängen. Dabei muss die Pin-Nummer von SDA sowohl bei SDA als auch bei I2C_DDR_REG_BIT gesetzt werden (also hier nicht die 7 wie oben geschrieben, sondern entweder die 3 oder 4, die Zuordnung geht aus Deinem Posting nicht ganz eindeutig hervor).

Schöne Grüße
Martin

Hallo,

der I2C-Bus funktioniert etwas anders, als Du es hier versuchst: Der Master schreibt die Adresse des Bauteils, welches er ansprechen möchte auf den Bus und liest dann entweder Daten vom Bus oder schreibt einen Befehl auf den Bus.

Diese Adresse setzt sich beim LM75 aus einem Herstellerteil, einem LM75-Teil und dem R/~W-Teil zusammen, die miteinander oder-verknüpft sind. Der Herstellerteil ist 0b1001 (<<4),der LM75-Teil hat 3 Bit (<<1), je nachdem, wie die Pins 5,6 und 7 mit Ground oder mit VCC verbunden sind. Welche Jumperstellung welchem Wert entspricht ist mir nicht ganz klar (bei einer flüchtigen Suche habe ich auch Hinweise gefunden, dass das Datenblatt die vertauscht hat). Deswegen einfach alle Jumper offen lassen und beide Werte ausprobieren, wenn es mit dem ersten nicht klappt. Das letzte Bit ist eine 1 für Lesen und eine 0 für schreiben. Damit muss als erstes Byte ein 0b1001xxx1 geschickt werden, mit xxx = 000 oder 111.

Somit muss Deine Code-Sequenz etwa so aussehen:

i2c_master_init();

while (1) {
	// Temperatur holen
	i2c_master_start();
	i2c_master_write(145); // Adresse senden, entspricht 0b10010001, alternativ 159 fuer 0b10011111
	temp = i2c_master_read(0); // mit ACK, den Wert merken
	temp2 = i2c_master_read(1); // mit NACK, den wert kann man verwerfen, wenn das LSB nicht interessiert
	i2c_master_stop();
	// temp >>= 1;   <-- dies ist nicht notwendig, da nur das high-byte der Temperatur verwendet wird 
	[...]

Das Datenblatt für den LM75 findest Du unter anderem hier. Dort ist auch auf Seite 11 die Bitsequenz dargestellt, die zum Lesen der Temperatur gesendet werden muss.

Das ist jetzt natürlich rein theoretisch, ich hoffe, dass es funktioniert...

Schöne Grüße,
Martin

Hallo,

Bibliotheken in C bestehen in der Regel aus 2 Teilen: einmal der Deklarationsteil in der Header (.h)-Datei, der nicht unbedingt notwendig ist, aber beim Compilieren Warnungen vermeidet bzw. auch Fehler verhindert (wenn eine Funktion z.B. uint_8-Werte erwartet oder zurückgibt, dann kann je nach Compiler das Aufrufen ohne dass die Funktion deklariert ist daneben gehen (weil Integerwerte ohne zusätzliche Information immer als int übergeben werden, und das ist beim AVR normalerweise int_16). Dieser wird mit dem #include eingebunden

Der zweite Teil besteht aus der Definition, also den eigentlichen Routinen, die in ".c"-Dateien abgelegt sind. Diese können entweder als Bibliothek eingebunden werden (dann werden die ".c"-Dateien vorcompiliert und zu einer Bibliothek zusammengefasst, die dann mit der Linkeroption -l hinzugefügt wird, wobei der Linker dann nur die Routinen auswählt, die wirklich benötigt werden), oder aber die Dateien werden mitcompiliert und dann mitgelinkt (dann werden alle Routinen eingebunden). Dies geschieht dann beim Linker. Da ich gerade nicht an die Dokumentation zu myAVR herankomme (die Webseite hat anscheinend aktuell Probleme beim Download der Dokumentation) und Dir deswegen gerade nicht die Compiler- und Linker-Optionen sagen kann, würde ich Dir empfehlen, den Inhalt der i2c_software_master.c einfach vor Deine eigene Routinen in Dein C-Programm zu kopieren (oder mit #include nach der ".h"-Datei einzubinden, auch wenn das an sich verpöhnt ist).

Schöne Grüße,
Martin

Hallo,

Zitat von Pesi

wegen dem Timer: Du machst ja SW-PWM, rufst also regelmäßig ne ISR auf - diese kannst Du ja auch gleich für weitere zeitbasierte Vorgänge benutzen, z.B. in der Timer-ISR ne Variable runterzählen, immer wenn die 0 ist, ein Flag setzen für "Zeitsegment abgelaufen" - in der Hauptschleife schaust Du dann, ob dieses Flag gesetzt ist, wenn ja, löscht Du es wieder, holst den Wert vom Sensor, "rechnest die Farbe aus" und schreibst sie in den PWM-Buffer...

wobei in diesem Fall (da nur ein Task abzuarbeiten ist) der einzige Unterschied zur Methode mit dem Delay im Hauptprogramm ist, dass sich im Fall des Delay die zeitlichen Variationen bei der Abarbeitung des PWM aufaddieren (also der Temperatursensor, wenn er denn 1 mal pro Sekunde gelesen werden soll, erst nach 1000.5 oder 999.5 oder so Sekunden zum 1000en mal ausgelesen wird), während bei der Interrupt-Methode die Absolutzeiten eingehalten werden. Die zeitlichen Variationen zwischen zwei Temperatur-Messungen sind die gleichen, genauso der Stromverbrauch oder die thermische Belastung.

Interessant wird damit das Auslösen der Messung im Interrupt für mich erst dann, wenn das Messen nebenläufig ist (also noch andere Aufgaben wie Kommunikation o.ä. durchgeführt werden), oder aber der Prozessor zum Stromsparen schlafen geschickt wird (was bei einer PWM allerdings nur begrenzt sinnvoll ist, da erstens der Prozessor sehr häufig aufwacht, zweitens 6 zusätzliche Takte zum Aufwachen braucht und drittens die Einsparung "nur" rund 70% entspricht).

Der Einfachheit halber würde ich in diesem Projekt jedoch darauf verzichten und bei der Delay-Methode bleiben (zumal es hier nicht wirklich darauf ankommt, ob nach 1 Sekunde oder 1.01 Sekunde die Temperatur gemessen wird). Ist aber sicher auch persönlicher Geschmack...

Ebenso persönlicher Geschmack, wenn ich mir Nenis Code ansehe: ich sichere entweder jeden Eingangswert ab (die While-Schleifen für Hue), oder ich verlasse mich darauf, dass die definierten Wertebereiche bei allen Variablen eingehalten werden; ich würde nur dann ausschließlich den Hue-Wert bei der 8-Bit-PWM absichern, wenn sat und bri als uint_8 definiert wären (was durchaus funktionieren sollte).

Ach ja: nicht vergessen, das Programm ordentlich zu kommentieren. Dabei mehr Wert darauf legen, zu beschreiben, wie es gemacht wird, nicht was gemacht wird - also nicht schreiben: setze Blue_val auf 255 - Saturation, das kann man nämlich direkt aus dem Code lesen, sondern etwa: Mische der Farbe in Abhängigkeit der Saturation Weiss bei, indem der Blauanteil umgekehrt proportional zur Saturation erhöht wird.

Diese Art der Kommentierung dauert deutlich länger als die "wörtliche", zeigt aber einerseits (natürlich nur, wenn die Kommentare richtig sind ) dass Du verstanden hast, was Du machst, andererseits helfen sie Dir dann auch, in 2 Jahren noch verstehen zu können, warum Du das genau so programmiert hast. Ich gebe aber gerne zu, dass ich hier auch gerne schlampe - mit den entsprechenden negativen Folgen Und der Code von Neni enthält schon einige "Tricks", die nicht direkt offensichtlich sind, wenn man nur die Wikipedia-Formeln kennt (Wertebereich Hue, um jede Farbe des entsprechenden RGB-Farbraums mit HSV darstellen zu können, Wahl der Konstanten, um durch 256 und nicht 255 teilen zu können, Auslagern der Multiplikation des V-Wertes an den Schluss um Speicherplatz zu sparen und Erhöhen des V-Wertes um 1 um durch 256 teilen zu können, eventuell auch noch weitere).

NACHTRAG: Während ich schreibe, seid ihr schon weiter zum Thema i2c / TWI: Der Vorteil dieses Busses ist, dass das Timing vollkommen egal ist, deswegen lässt er sich auch recht einfach in Software ohne Interrupt abbilden (ist allerdings schon etwas aufwändiger, ein Beispiel für die Megas findest Du ebenfalls bei Mikrocontroller.net ; hier musst Du nur einfach die Funktionen Deinem Programm hinzufügen). Dann würde ich die Kommunikationsroutinen jedoch auf alle Fälle nicht im Interrupt laufen lassen (also entweder wie bei Pesi über Timer getriggert im Hauptprogramm, oder einfach mit Delay im Hauptprogramm). Ach ja, falls Du fremden Code verwendest, bei dem offensichtlich ist, dass er in der Dir zur Verfügung stehenden Zeit nicht von Dir entwickelt worden sein kann, solltest Du das im Kommentar darstellen; bei anderem "geborgten" Code ist es höflich (aber eventuell nicht der Note förderlich - Kommentiere ihn aber zumindest zusätzlich, so dass er nicht direkt bei einer Google-Suche "herausspringt" ) Falls Neni als Urheber genannt werden möchte, wird er es Dir sicherlich mitteilen...

Schöne Grüße,
Martin

Zitat von Organized

Habe jetzt die PWM im 8bit-Timer. Wo soll ich denn nun die Berechnung hinpacken? So wie ich das beim 16bit-Timer verstanden habe, kann der keine Interrupts auslösen?

Auch der 16-Bit-Timer kann Interrupts auslösen, beim ATMega8 muss man dafür z.B. Bit 2 (TOIE1) in Register TIMSK setzen, um bei einem Overflow einen Interrupt zu erzeugen.

Zitat von Organized

Die Berechnung also in die Main und mit _delay_ms(); bremsen?

Wenn Dein Mikroconroller nichts anderes machen soll, ist das die einfachste Variante - wenn beide Aufgaben in verschiedenen Interrupts ausgeführt werden, muss man sich Gedanken darüber machen, dass der ATMega von Haus aus keine Interrupt-Priorisierung kennt, was ohne Gegenmaßnahmen dann gelegentlich zu (leichtem) Flackern führen würde, wenn an sich die PWM-Routine 'dran wäre, der Prozessor jedoch gerade im Temperatur-Interrupt steckt. Und das Du prinzipiell mit Timern und Interrupts umgehen kannst, hast Du dann ja schon mit der PWM-Routine gezeigt.

@Neni:
Respekt für die Berücksichtigung der Besonderheiten beim Teilen durch 256, ich muss zugeben, dass ich mir die Konstanten nicht so genau angesehen hatte - bei verschiedenen anderen Routinen, die man im Netz finden kann, sind sie nicht berücksichtigt worden, was ich dann fälschlich auf Deine Routine übertragen habe. Was ich so direkt allerdings nicht aus Deinem C-Code ablesen kann ist, was Du unter "Light-Emission-normalized" verstehst?

Schöne Grüße,
Martin

Hallo,

da es eine Schulaufgabe war, wollte ich es ihm nicht zu leicht machen - auf Fragen des Lehrers kann man nur antworten, wenn man das Prinzip verstanden hat, und das fällt mir am leichtesten, wenn ich etwas selbst entwickele. Das Beispiel von Neni benutz übrigens auch Festkommaarithmetik, auch wenn es nicht so genannt wird (S,V,R,G,B sind ufix( 8 )mit 2^8 skalierung, H ist ufix(16) mit 'ner Skalierung von 4.24). Programmtechnisch ist die Division durch 256 sicherlich einfacher als durch 255, allerdings bekommt man damit niemals die maximale Helligkeit (da 255*255 / 256 = 254). Ich habe deswegen bewusst die 255 gewählt; aus dem gleichen Grund habe ich nicht den vollen Bereich von 255 für H vorgeschlagen, da die Beschränkung auf 240 (also eine Skalierung von 2/3) eine schöne Skalierung der 60°-Sektoren erlaubt (bei der Ausnutzung des Wertebereiches eines Bytes müsste an sich mit 42,5 gerechnet werden. Benutzt man dann die 42, so geht wieder Genauigkeit verloren).

Ich gebe aber gerne zu, dass dies eher akademische Probleme sind, die in der Realität nicht sichtbar sind. Den Lehrer könnten sie aber interessieren...

Deutlich wichtiger was die Sichtbarkeit angeht ist sicherlich, die PWM nicht ungetaktet im Hauptprogramm ablaufen zu lassen, damit eine unterschiedliche Arbeitsbelastung des Mikrocontrollers nicht zum flackern führt (z.B. beim Einlesen der Temperaturen).

Schöne Grüße,
Martin

Hallo,

zu Deiner Frage: regelmäßige Aufrufe von Funktionen macht man bei Mikrocontrollern mit einer Interrupt-Routine, die von einem der eingebauten Zeitgebern (Tmer) ausgelöst wird. Zum Einlesen eignet sich das AVR Tutorial von Mikrocontroller.net.

Zu Deinem Code: Leider muss man sich bei 8-Bit Mikrocontrollern etwas mehr Gedanken machen, was die Datentypen können und was nicht, als bei einem ausgewachsenen PC. So wird Deine HSV-Berechnung so leider nicht funktionieren: Du setzt H auf Temp*6, S und V auf 1. In H ist also in dem Beispiel 78.

hi setzt Du auf H / 60, also auf 1 (da hi ein uint_8 ist, wird der Komma-Anteil einfach abgeschnitten). f setzt Du auf H/60 (also 1, da der komplette Ausdruck in Integer gerechnet wird) - hi (=1), also auf 1-1 = 0. Das ändert sich für <10°C auf hi=0 und f=0, für 20°C-30°C auf hi=2 und f=0, für 30°C-40°C auf hi=3 und f=0 u.s.w. f ist also immer 0. Damit ist aber p = 0, q = V (=1) und t=0 (und zwar unabhängig von der Temperatur).

Damit wird in Abhängigkeit der Temperatur Rot (<10°C und >50°C), Grün(10°C-30°C) oder Blau (30°C-50°C) ganz schwach leuchten. Schwach deswegen, da V=1 und damit R, G, B entweder 1 oder 0. Damit werden aber die entsprechenden LEDs bei i=0 (bzw. 255) eingeschaltet und im übernächsten Durchlauf (der sehr schnell sein kann) wieder ausgeschaltet.

Damit hast Du hier zwei Hauptprobleme: Dadurch, dass die Berechnungen in uint_8 (bzw. int16) durchgeführt werden, bekommst Du nicht den Fabmix, den Du haben willst, und es leuchtet kaum (bei double-Berechnung wäre der Wertebereich von p,q,t zwischen 0 und 1). Du solltest hier die Variablen als Fixkomma-Variale mit Skalierung verwenden - also die Berechnung z.b. in int16 durchführen (dabei allerdings die Berechnung von f durch den Modulo-Operator durchführen), H in Abhängigkeit von dem gewünschten Temperaturbereich skalieren, so dass es zwischen 0 und 240 liegt (dann aber auch nicht durch 60, sondern durch 40 teilen) und S und V auf 255 setzen - H ist also im Vergleich zum Wikipedia-Artikel mit 2/3, S und V mit 255 multipliziert. Da f dann weiterhin zwischen 0 und 1 liegen würde, muss es entsprechend skaliert werden (geschieht, indem man einfach f= H % 40 statt f=H/40-hi rechnet - dies entspricht einer Multiplikation mit 40). Zuletzt noch die p,q,t-Berechnungen passend skalieren, indem die erste 1 durch eine 255 ersetzt wird und dafür der Gesamtausdruck durch 255 geteilt wird.

Jetzt gibt es nur noch zwei Sachen: erstens müssen die Produkte von f durch 40 geteilt werden (da f ja mit 40 skaliert worden ist) - allerdings muss im Ausdruck (1-f) dafü auch die 1 durch eine 40 ersetzt werden. Zum Anderen ergibt sich ein Genauigkeitsverlust bei q und t, da zwei relativ kleine Zahlen voneinander abgezogen werden. Dies kann man dadurch verbessern, dass man das Teilen durch 40 erst nach der Subtraktion durchführt - dann muss allerdings die Konstante auch passend skaliert werden.

Es ergibt sich somit für die Berechnung von p,q und t folgendes:

hi = H / 40
f = h % 40

p = (V * (255-S)/255
q = (V* ( ( (255*40) - (S*f))/40)) / 255
t = (V *( ( (255*40) - (S*(40-f)))/40))/255

p, q und t liegen damit im Bereich zwischen 0 und 255 und damit in dem Bereich, den Du erwartest. Du musst nur noch dafür sorgen, dass Dein H im Bereich zwischen 0 und 240 liegt.

Neben dem Einlesen derTemperatur-Werte und Berechnen der RGB-Größen in einem Interrupt, solltest Du Dir überlegen, ob Du nicht auch die PWM in einen Timer-Interrupt ausagern möchtest. Das reduziert dann die Rechenlast erheblich. Auch würde sonst der Temperatur-Task die PWM stören, und die LED würde unregelmäßig flackern.

Und um noch einen möglichen Stolperstein im Vorraus aus dem Weg zu räumen: Globale Variablen, die in Interrupt-Routinen verwendet werden, müssen als volatile gekennzeichnet sein, damit der Compiler weiss, dass diese Variable jederzeit geändert werden kann (sonst können eventuell Optimierungen dazu führen, dass die Variable nicht so verwendet wird, wie du es erwarten würdest.

Ansonsten noch viel Spass mit der Schulaufgabe - falls Du meine Erklärung zu Festkommazahlen-Arithmetik nicht verstanden haben solltest, könnte Dir auch hier eventuell die Wikipedia weiterhelfen.

Schöne Grüße,
Martin

Hallo,

zu 2: würde ich mit einer HSV zu RGB-Umrechnung machen; (H)ue über die Temperatur, S(aturation) auf max und (V)alue auch auf max ergibt das gesamte Spektrum von Rot über Gelb, Grün, Blau bis Lila. Siehe auch Wiki-Artikel zu HSV.

zu 3: Ist einfach mit einer Soft-PWM zu machen, bei 3 Kanälen kannst Du eine beliebige Methode nehmen, die Rechenleistung vom Mega8 reicht in jedem Fall aus.

Schöne Grüße,
Martin

Hallo,

aktuell hab' ich das in testweise einer speziellen Version des Lichtknoten, die ins Bad soll, und dort 18 Fliesenkreuze ansteuern wird (sowie einen Bewegungsmelder aufnehmen und ins CAN-Netzwerk melden soll).
Bei 14 Bit und der vorgeschlagenen angepassten Tabelle dimmt die 5050 20mA warmweisse LED schön gleichmäßig auf und ab - bis auf die niedrigsten 4-8 Werte, da sieht man ein leichtes "stottern". Das ist aber auch zu erwarten, da hier ja prozentual die größten Sprünge stattfinden, und das Auge einen wesentlich größeren Helligkeitsbereich als 1e5 hat (schon der erste Wert ist bei dieser LED deutlich sichtbar).

Ich hab' einfach mal meine BCM-Routine zum Vergleich angehängt - die Umbenennungen sind größtenteils eine Anpassung an die bisherigen Bezeichnungen. Ist allerdings auf den gcc-assembler umgeschrieben und die Register werden am Anfang der Routinen alle gesichert. Auch wird das Neuberechnen der Register innerhalb der ISR angestoßen (meine Kommunikationsroutinen vertragen auch 'mal längere Auszeiten). Lässt sich bestimmt auch noch weiter optimieren, allerdings bin ich durch den Hausbau inzwischen von "so gut wie möglich" auf "so gut wie notwendig" umgestiegen.

Ich werde das jedenfalls auch in die anderen Lichtknoten nachrüsten, da das - im Gegensatz zur PWM - überhaupt nicht mit den 3D-Shutterbrillen des Fernsehers interferiert (also selbst durch diese Brille faded die LED gleichmäßig auf und ab).

Schöne Grüße,
Martin

P.S.: Hab' gerade nochmal die erste Seite gelesen: bei mir werden die LEDs jeweils von einem BCR402 getrieben, für den ist das also nicht zu schnell...

Hallo,

mir ist aufgefallen, das in der Routine Bitsdrehen das Z-Register verwendet, das aber nicht gesichert wird. Eventuell liegt's daran? Zu dem Timer-Interrupt kann ich leider nichts sagen:
Da ich ja eine spezielle Anwendung habe (22 LEDs - bzw. 6 RGB + 1 RGBW), die auf 4 Ports eines PWM3b verteilt sind, musste ich größere Teile komplett umschreiben, aber jetzt funktioiert es bei mir auch im Rahmen der restlichen Anwendung (14 Bit mit 2 Takten LSB). Einen herzlichen Dank deswegen noch an den TE für die Inspiration!

Schöne Grüße,
Martin

Hallo,

mein Beitrag sollte nicht überheblich wirken, beim jetzigen Lesen stelle ich fest, dass er etwas so klingen könnte, sorry.

Ich geb' Dir recht, bei 8 Bit und 56 Kanälen ist's wahrscheinlich nicht mehr so prickelnd, auch wenn man natürlich neben der reinen Anzahl der Aufrufe auch noch beachten muss, dass bei 56 Kanälen die direkte Methode in jedem der 255 Interrupts auch 56 Abfragen (und bei gleichen Werten auch 56 Ausgaben) durchführen muss, während die "intelligente" Methode bei 56 Interrupts jeweils nur 7 Ausgaben und 1 Timer-Setzen durchführen muss. Das Sortieren kostet allerdings wirklich Rechenzeit.

Ich hab' auf diese Weise eine 10 Bit 22-Kanal-PWM implementiert, da war der Vorteil für die "intelligente" Methode doch erheblich, trotz sortieren. Die 10 Bit waren notwendig, um wenigstens etwas Gama-Korrektur machen zu können. Da passte dann auch noch ein CAN-Stack sowie eine Lichtprogramm-Ablaufsteuerung hinein (bei 16 MHz).

Allerdings ist die BCM tatsächlich die (noch) "intelligentere" Methode, ich muss 'mal sehen, ob ich die für diesen Zweck implementiert bekomme (6 RGB + 1 RGBW-LED an einem AT90PWM3b, der auch noch einen CAN-Controller bedient, da muss man auch etwas seine Bits sortieren, da die auf 4 Ports verteilt sind). Ein weiterer Vorteil der BCM-Methode ist, dass erheblich weniger RAM verbraucht wird - in meinem Fall für die PWM-Timer 23*2 (aktuelle + vorsortierte Timerwerte) * 2 Byte = 92 Byte und die Masken 23*2*3 Byte =138 Byte, also in Summe 230 Byte gegen 4*10 = 40 Byte BCM-Speicher. Und bei dem ganzen anderen Kram werden die 512 Byte, die der PWM3b hat, sehr schnell knapp.

Schöne Grüße,
Martin

Hallo,

zum Thema PWM in Software ist das Tutorial bei mikrocontroller.net stark zu empfehlen:

Soft-PWM

Die von Pesi dargestellte direkte Methode ist für eine größere Anzahl von PWMs eher suboptimal, da sind Optimierungen mit dem Faktor 30-40 'drin. Dann klappt es auch mit dem ganzen Rest.

Ich würde allerdings (inzwischen) auch dedizierte Treiber-ICs verwenden, da diese eine höhere Auflösung, eine Gamma-Korrektur und eine Konstantstromquelle bieten.

Schöne Grüße,
Martin

Hallo,

Zitat von i love my cree

Dein LED-Treiber ist im übrigen für Feuchträume ungeeignet

Das häusliche Bad gilt nicht als Feuchtraum, wenn keine bodengleiche Dusche und kein Bodenabfluss vorhanden ist. Einzuhalten sind aber auf alle Fälle die Installationszonen, wobei es über einer abgehängten Decke, so die Raumhöhe mindestens 2,25 m entspricht, für die Betriebsmittel keine Einschränkungen gibt.

Das heisst aber nicht, dass es nicht durch die Feuchtigkeit zu Korrosionsschäden kommen kann. Nur eben das Risiko eines elektrischen Schlages ist ausreichend gering...

Schöne Grüße,
Martin

Hallo,

darf ich fragen, welche Halle Du mit 200 MC-E RGBW beleuchten möchtest? Bei meinen Experimenten fand' ich, dass eine MC-E in etwa vergleichbar mit einer 20 W Halogenlampe ist (bei 500 mA) - da erscheinen mir Rundplatinen mit 4 von denen, und dann auch noch 20 bis 50 davon als recht viel...

Zur Ansteuerung: Wenn eh' über eine eigene Intelligenz pro Strahler nachgedacht wird, kann man gleich eine kleine Platine mit Controller und 4 Konstantstromquellen aufbauen. Wählt man dann noch die passende Versorgungsspannung, dann lohnen sich Schaltregler schon fast nicht mehr (o.k., Gesamt-Wirkungsgrad liegt dann je nachdem "nur" so bei 70% (1 LED bei 5 V) oder 90% (3 LED bei 12V), aber was solls...). Dann kann man z.B. 'nen BCR402 oder etwas ähnliches nehmen, dann wird das ziemlich klein... Interface lässt sich dann beliebig wählen.

Wenn mich der Rest vom Haus nicht so beschäftigen würde, könnte ich Dir auch schon sagen, ob meine theoretische Helligkeitsüberlegung (oben) in der Realität funktioniert (geplant sind 30 MC-E RGBW und 180 High-Power PLCC 6 für's Wohnzimmer/Esszimmer, zusammen so 60 qm; Ansteuerung je 1 MC-E und 6 PLCC über 22 BCR402 mit einem AT90PWM3b mit MCP2515/TJA1050 CAN-Controller). Platinen sind fertig, LEDs liegen hier, nur die Decke fehlt noch...

Schöne Grüße,
Martin

Hallo,

bei mir ebenso alles wunderbar angekommen. Vielen Dank noch einmal dafür!

Schöne Grüße,
Martin