Machbarkeit - LED-Sternenhimmel mit AVR?

[D. K. (Gast)]

Hallo zusammen,

Ziel ist es, einen "Sternenhimmel" mit LEDs zu realisieren. Es soll kein 
echter Sternenhimmel (im Hinblick auf Sternzeichen) sein sondern 
willkürlich sollen LEDs einzeln zufallsgesteuert ein- und ausblenden. 
Die Ein- bz.w Ausblendedauer soll dabei zufällig lang sein (innerhalb 
gewisser Grenzen um Blitzen o.Ä. zu vermeiden). Es sollen ca. 30-50 LEDs 
am Himmel verbaut werden, die jedoch nicht gleichzeitig an sein soll 
bzw. müssen.

Zum Einsatz sollte ursprünglich ein MEGA16@12MHz kommen.

Nachdem ich schonmal ein bißchen rumprobiert habe habe ich irgendwie das 
Gefühl, daß ich mit einem reinen AVR nicht glücklich werde. Zum einen 
kann der AVR den Strom nicht treiben, zum anderen habe ich irgendwie das 
Gefühl, daß die Umsetzung der PWM in SW bei einer derartigen Anzahl von 
LEDs für die µC zu viel ist.

Frage 1: Kann das sein, daß der AVR damit überfordert ist?

Da ich es schon ganz gern hinkriegen würde habe ich mir folgende 
Alternativen überlegt:

1.) Einsatz eines FPGAs, das sich um die reine PWM kümmert. Das FPGA 
liest die Zielwerte der LEDs vom AVR ein (SPI oder eine wie auch immer 
geartete Implementierung). Am Ausgang des FPGA hängen dann die 
Treiberstufen und fertig ist der Lack.

Vorteil:
- PWM wird ausgelagert und das AVR muss sich nur noch um Kommunikation 
und Berechnung der Werte kümmern.

Nachteil:
- Bin mit FPGA und VHDL nicht mehr ganz so firm
- evtl. mit Kanonen auf Spatzen geschossen

2.) Einsatz eines LED-PWM-IC (TI TLC5922), davon dann halt mehrere.

Vorteil:
- PWM wird ausgelagert und das AVR muss sich nur noch um Kommunikation 
und Berechnung der Werte kümmern.

Nachteil:
- bei der LED-Anzahl sind mehrere TLC nötig

Frage wäre also:

1.) Ist meine SW-Implementierung Grütze und der AVR müsste es schaffen, 
die Berechnung der Zeiten sowie SW-PWM zu realisieren oder sind hier die 
Grenzen des µC erreicht?

2.) Falls die Grenzen erreicht sind, welche Lösung würde sich dann als 
Alternative empfehlen?

Grüße und Danke,

  Danny

[::: (Gast)]

Angefangen damit, dass ein AVR diese Anzahl ausgaenge nicht ansteuern 
kann, benoetigt man einen Portexpander, zB in der form eines Satzes 
schieberegister 74HC595. Da kann man an jeden ausgang eine LED haengen 
und so nahezu beliebig viele LED ansteuern. Ich wuerd jede LED mit zB 
1mA betreiben, das wir immer noch hell genug. Den PWM macht man, in dem 
man alle LED zB 1000 mal pro sekunde neu ansteuert.

[guest (Gast)]

wieso nicht einfach 2 atmegas? dann hast du 64 ports für 64 leds ^^

[Christian H. (netzwanze)]

Oder mehrere MAX7301 (jeweils 28 GPIOs).

[Gast (Gast)]

1*ATmega16 mit 24 LEDs bei 8Bit Software PWM hab ich hier laufen.
Es funktioniert also, wie schon geschrieben 2*AVR und dein Sternenhimmel 
ist machbar.

[Daniel Widmann (Gast)]

Hallo,

ich habe erst vor kurzem eine SW PWM für 4 RGB LEDs, also 12 Kanäle, 
geschrieben. Funktioniert mit 1024 PWM Schritten auf einem Mega48 mit 8 
MHz ohne Flimmern. Also es ist technisch auf jeden Fall möglich sowas in 
Software zu realisieren. Ich musste jedoch einige Tricks in die Software 
PWM einbauen, damit das in der Geschwindikeit läuft. Falls man mehr 
Kanäle braucht wie der AVR Portpins hat, muss man mehrere 
Mikrocontroller verwenden.

Gruß Daniel

[MaWin (Gast)]

> Kann das sein, daß der AVR damit überfordert ist?

Nein, der AVR könnte nebenbei noch eine Waschmaschine steuern.

Bei nur 30-50 LEDs reichen sogar dessen Ausgänge und man muss nicht mal 
Multiplexbetrieb machen (für den man sowieso externe Verstärker 
bräuchte, selbst für 2mA pro LED)

Sicher, 20mA pro LED und 32 LEDs wären 640mA die über den GND Anschluss 
laufen und damit offiziell zu viel (TQFP Gehäuse steht besser da). 
Praktisch haelt er das aber aus, ausserdem kann man die Haelfte der LEDs 
an VCC und die andere Haelfte an GND anschliessen. Mit etwas Intelligenz 
ist das also hinzubekommen. Auch beim Programmieren ist in Assembler 
sicherlich viel Luft, waehlt man irgendwas interpretiertes höheres als 
Programmiersprache wird's ggf. eng.

[Karl H. (kbuchegg)]

Ich habe bereits einen Sternenhimmel gebaut.

64 Leds an 8 Schieberegister 595.
Der verwendete Mega8 schafft es bei ~11Mhz leicht, die 64 Leds mit 
Software-PWM un 64 Helligkeitsstufen anzusteuern.

Ich habe einen parametrisierbare Formel für das Flackern der Leds 
benutzt. Jede Led durchläuft 2 Zyklen: Hell - Dunkel.
Für jeden Zyklus bestimmt ein Zufallszahlengenerator jeweils
    Dauer
    Helligkeit

Wobei sich beide Parameter jeweils nach einer linearen Gleichung 
zusammensetzen

    Dauer = Dauerbasis + Offset * random

Durch Wahl von Basis und Offset (wobei Offset durch den zufälligen 
Anteil random modifiziert wird) ist es möglich fgestzulegen: Die Dauer 
des Zyklus beträgt minimal zb 10 Sekunden und wird zufällig noch um bis 
zu 5 Sekunden verlängert.

Selbiges für Helligkeit.

Durch die Wahl von anderen Parametern ist es möglich eine ganze Reihe 
von unterschiedlichen Charakteristikien für den Himmel festzulegen.

geringe Helligkeit aller Leds, ab und zu wird eine heller
alle Leds aus, einzelne Leds blitzen ab und zu auf
alle Leds aus, Leds blitzen in schneller Folge zufällig hell auf
gleichmässige Grundhelligkeit, einzelne Leds pulsieren in schneller 
Folge
....

[Gast (Gast)]

Das geht problemlos mit ein paar 595er Schieberegister. 6 
Schieberegister kaskadiert kann man problemlos so schnell ansteuern, 
dass eine Dimmung mit 128 Stufen möglich ist. Sowas hab ich hier am 
laufen, vermutlich wären sogar 256 Stufen möglich, hatte aber noch keine 
Zeit, um es zu testen.

[Marko B. (glagnar)]

Da gibts ein paar nette Chips von TI:

http://focus.ti.com/paramsearch/docs/parametricsearch.tsp?family=analog&familyId=480&uiTemplateId=NODE_STRY_PGE_T

Bis zu 24 PWM-Kanäle.

[D. K. (Gast)]

Hallo zusammen (oder besser Guten Morgen),

danke schonmal für die Antworten! Werde mir die Postings nochmal im 
Detail ansehen, Interessant, einige Namen aus d.s.e. hier 
wiederzufinden! :)

Viele Grüße,

  Danny

[Michael B. (babble)]

Hallo,
ich habe eine Frage an Hr.Karl heinz Buchegger die LED Schaltung mit 
959er von der sie weiter oben geschrieben haben, kann man den Schltplan 
und das Programm hier im Forun herunter laden?
Mfg Babble

[Fabian B. (fabs)]

Ich habe sowas nach dem Vorbild von dem System von kbuchegg auch gebaut. 
Allerdings mit (glaube) 118 LEDs mit je 32 Helligkeitsstufen auf 1,60m x 
1,20m verteilt. Das ganze wird gesteuert von einem 644 mit 20MHz, der 
die LEDs über TPIC6B595 ansteuert. Das ganze hängt an einem AC-DC 
Netzteil und ist steuerbar über eine Funkfernbedienung mit RFM12.
Codemässig hab ich starke anleihen bei kbuchegg, aber noch etwas 
erweitert...
Bei Interesse such ich heut abend mal ein - zwei Bilder raus.

Gruß
Fabian

[Karl H. (kbuchegg)]

Michael B. schrieb:
> Hallo,
> ich habe eine Frage an Hr.Karl heinz Buchegger die LED Schaltung mit
> 959er von der sie weiter oben geschrieben haben, kann man den Schltplan
> und das Programm hier im Forun herunter laden?

Nein, leider nicht.
Der Originalcode ist mitlerweile auch mit einer alten Festplatte 
irgendwo verschwunden. Er ist aber nicht so schwer. Das war damals eine 
Arbeit auf ein paar Abende.

Erstes Zwischenziel ist es, die PWM Steuerung hinzukriegen. Das war bei 
mir ein Timer, der einen regelmässigen Overflow Interrupt ausggelöst 
hat.

Im Grund also sowas (nicht schlagen, ich mach das jetzt aus dem 
Gedächtnis)

#define SR_PORT  PORTB
#define SR_DATA    PB0      // Dateneingang vom Schieberegister   SER
#define SR_CLOCK   PB1      // Clock Eingang vom Schieberegister  SCK
#define SR_STROBE  PB2      // Datenübernahme im Schieberegister  RCK

unsigned char Intensity[64];
unsigned char PWMCount;

ISR( TIMER2_OVF_vect )
{
  unsigned char i;

  PWMCount++;
  if( PWMCount == 64 )
    PWMCount = 0;

  for( i = 0; i < 64; ++i ) {
    // je nach PWM eine 0 oder eine 1 in das SR schieben
    if( Intesity[i] > PWMCount )
      SR_PORT &= ~( 1<< SR_DATA );
    else
      SR_PORT |= ( 1 << SR_DATA );
    SR_PORT |= ( 1 << SR_CLOCK );
    SR_PORT &= ~( 1 << SR_CLOCK );
  }

  SR_PORT |= ( 1 << SR_STROBE );
  SR_PORT &= ~( 1 << SR_STROBE );
}

Dazu noch den Timer konfigurieren und dann sollten eigentlich die LED 
sich einschalten lassen, indem man in Intensity Werte reinschreibt.
Den Timer hab ich mir so eingestellt, dass die ISR gerade gut fertig 
geworden ist, ehe der nächste Overflow kommt.

int main()
{
  // Timer konfig
  // ...


  sei();   // ab jetzt laufen die LED

  for( i = 0; i < 64; ++i )
    Intensity[i] = i;

  while( 1 )
    ;
}

Das sollte die LEDS unterschiedlich hell einschalten. Jede der 64 mit 
einer anderen Intensität.

[Karl H. (kbuchegg)]

Darüber liegt dann noch eine 2-te Zeitsteuerung.

Wenn ich mich recht erinnere, habe ich mir fü jede LED eine Struktur 
zurechtgelegt

struct ledData
{
  unsigned char Intensity;
  unsigned char ItensityDunkel;
  int HellTime;
  int Time;
};

int BaseIntensHell;
int RandIntensHell;
long BaseTimeHell;
int RandTimeHell;
int BaseIntensDunkel;
int RandIntensDunkel;
long BaseTimeDunkel;
int RandTimeDunkel;


struct ledData LedData[64];

Ob ich da jetzt überall int genommen habe oder nicht, weiß ich nicht 
mehr.

Wenn ich mich recht erinnere habe ich brutalerweise das Berechnen der 
nächsten Einstellung mit in die PWM-ISR gelegt. (Ich war jung und 
brauchte das Geld)

Irgendsowas

ISR( TIMER2_OVF_vect )
{
  unsigned char i;

  PWMCount++;
  if( PWMCount == 64 )
    PWMCount = 0;

  for( i = 0; i < 64; ++i ) {
    // je nach PWM eine 0 oder eine 1 in das SR schieben
    if( LedData[i].Intesity > PWMCount )
      SR_PORT &= ~( 1<< SR_DATA );
    else
      SR_PORT |= ( 1 << SR_DATA );
    SR_PORT |= ( 1 << SR_CLOCK );
    SR_PORT &= ~( 1 << SR_CLOCK );

    if( LedData[i].Time < LedData[i].HellTime )
      LedData[i].Intensity = ItensityDunkel;

    if( LedData[i].Time > 0 )
      LedData[i].Time--;
    else {
      LedData[i].Intensity = ( BaseIntensHell + randomize( RandIntensHell ) ) % 64;
      LedData[i].ItensityDunkel = ( BaseIntensDunkel + randomize( RandIntensDunkel ) ) % 64;

      LedData[i].Time = BaseTimeDunkel + randomize( RandTimeDunkel );
      LedData[i].HellTime = BaseTimeHell + randomize( RandTimeHell );
    }
  }

  SR_PORT |= ( 1 << SR_STROBE );
  SR_PORT &= ~( 1 << SR_STROBE );
}

Hmm. Das kommt mir jetzt komisch vor. Bin mir nicht mehr sicher, ob ich 
wirklich eine derart große Workload in die ISR gelegt habe, oder ob ich 
die Neuberechnung nicht in die main-Loop ausgelagert habe. Auf der 
anderen Seite passiert die Neuberechnung der Leds ja relativ selten (aus 
Sicht der ISR). Dagegen kann man halten, dass die ISR so schnell wie 
möglich sein soll, und ob die Neuberechnung ein paar hunderstel Sekunden 
zu spät kommt, interessiert auch niemanden. Das würde eher für eine 
Neueberechnung in der Mainloop sprechen. Also so was

ISR( TIMER2_OVF_vect )
{
  unsigned char i;

  PWMCount++;
  if( PWMCount == 64 )
    PWMCount = 0;

  for( i = 0; i < 64; ++i ) {
    // je nach PWM eine 0 oder eine 1 in das SR schieben
    if( LedData[i].Intesity > PWMCount )
      SR_PORT &= ~( 1<< SR_DATA );
    else
      SR_PORT |= ( 1 << SR_DATA );
    SR_PORT |= ( 1 << SR_CLOCK );
    SR_PORT &= ~( 1 << SR_CLOCK );

    if( LedData[i].Time > 0 )
      LedData[i].Time--;
  }

  SR_PORT |= ( 1 << SR_STROBE );
  SR_PORT &= ~( 1 << SR_STROBE );
}

int main()
{
   int NewIntensHell, NewIntensDunkel;
   long NewTimeHell, newTimeDunkel;

   ...

  i = 0;

  while( 1 ) {

    cli();
    if( LedData[i].Time < LedData[i].HellTime )
      LedData[i].Intensity = LedData[i].ItensityDunkel;
    sei();

    // gib dem Overflow eine Chance

    cli();
    if( LedData[i].Time == 0 ) {
      sei();
      NewIntensHell = ( BaseIntensHell + randomize( RandIntensHell ) ) % 64;
      NewTimeHell = BaseTimeHell + randomize( RandTimeHell );
      NewIntensDunkel = ( BaseIntensDunkel + randomize( RandIntensDunkel ) ) % 64;
      NewTimeDunkel = BaseTimeDunkel + randomize( RandTimeDunkel );
      cli()
      LedData[i].Intensity = NewIntensHell;
      LedData[i].ItensityDunkel = NewIntensDunkel;
      LedData[i].HellTime = NewTimeHell;
      LedData[i].Time = NewTimeHell + NewTimeDunkel;
    }
    sei();

    i++;
    if( i = 64 )
      i = 0;
  }
}

Ach ja: randomize basiert auf rand() und hat die Aufgabe eine 
Zufallszahl von 0 bis zur angegebenen Grenze zu bestimmen.


Über dem ganzen lag bei mir dann noch eine UART Empfangseinheit, mit der 
man die Vorgabwerte BaseXXX und RandXXX verändern kann.
Ich habe meinen Himmel 2-geteilt. Ein Mega8 ist nur für die PWM und das 
Funkeln zuständig. Der andere hat ein LCD und Tasten drann, in dem man 
menügeführt die Werte verändern kann. Die Kommunikation ist eine normale 
UART. Das hatte 2 Vorteile
* zum einen konnte ich die PWM-Einheit vom Hyperterminal aus testen,
  ohne die Anzeigeeinheit fertig zu haben
* zum anderen ist in beiden Mega8 ein Bootloader drinnen, mit dem ich
  Updates vom PC aus einspielen kann. Der PWM-Mega8 sitzt unter der
  Decke und an den komme ich physikalisch nicht mehr ran. Um dem ein
  Update einzuspielen stopsle ich ihn einfach von seiner Anzeigeeinheit
  ab, dann kommt der PC an das Verbindungskabel und der Bootloader
  macht den Rest.

[Fabian B. (fabs)]

Also in der ISR wurde nur das Rausschieben an die Schieberegister 
gemacht... die Neuberechnung war meiner Erinnerung nach im 
Hauptprogramm.

An ein Struct kann ich mich jetzt aber auch nicht erinnern, das war 
alles über Arrays gelöst.

Die ISR verbraucht bei mir trotzdem den Grossteil der Rechenzeit, darum 
sinds bei mir eben auch keine 64 Helligkeitsstufen mehr.

Ich kann, bei Interesse, den Code heut abend nochmal posten... ich 
müsste den noch haben.

Gruß
Fabian

[Karl H. (kbuchegg)]

Fabian B. schrieb:
> Also in der ISR wurde nur das Rausschieben an die Schieberegister
> gemacht... die Neuberechnung war meiner Erinnerung nach im
> Hauptprogramm.

Wie gsagt, kann mich nicht mehr genau daran erinnern.

>
> An ein Struct kann ich mich jetzt aber auch nicht erinnern, das war
> alles über Arrays gelöst.

Kann sein.

>
> Die ISR verbraucht bei mir trotzdem den Grossteil der Rechenzeit, darum
> sinds bei mir eben auch keine 64 Helligkeitsstufen mehr.

Ja, das war bei mir auch so

> Ich kann, bei Interesse, den Code heut abend nochmal posten... ich
> müsste den noch haben.

Sei so lieb.

[Master S. (snowman)]

ich habe nicht alles durchgelesen, aber meine erfahrung bezüglich LEDs 
ansteuern und rechenleistung: ich habe einen 8bit-PIC mit 12MPIS, der 
einen LED-cube mit 216 LEDs ansteuert und 80Hz bildwiederholfrequenz hat 
(also nix flimmern) allerdings kein PWM, und die auslastung für nur die 
anzeige als solches braucht etwa 3% der rechenzeit (ich hoffe, dass ich 
die zahl recht in erinnerung habe. ich weiss nur, dass ich sie extra mal 
nachgemessen habe und erstaunt war, dass sie "nichts" ist).
wenn ich das mal hochrechne auf 8bit-PWM müsste ich somit auf 24% 
rechenauslastung kommen und das bei 216 LEDs (mache ich einen 
denkfehler?)

[Alex W. (a20q90)]

Kurz zur Info:

Mit einem M32 und einigen Latches kann man mindestens 768 LEDs 
ansteuern, und die auch noch mit 8Bit PWM für jede einzellne!

Der M32 kann das! Sogar in Basic!

[Master S. (snowman)]

nachtrag: ich habe einen rechenfehler beim hochrechnen gemacht: ich 
bräuchte 3% * 256 = 768% rechenzeit ;-) ..aber brauchts wirklich 
8bit-PWM für einen sternenhimel? die sterne dürfen doch auch mal etwas 
"blinkend" wirken

[Karl H. (kbuchegg)]

Master Snowman schrieb:
> nachtrag: ich habe einen rechenfehler beim hochrechnen gemacht: ich
> bräuchte 3% * 256 = 768% rechenzeit ;-) ..aber brauchts wirklich
> 8bit-PWM für einen sternenhimel? die sterne dürfen doch auch mal etwas
> "blinkend" wirken

Genau darum bin ich nicht auf 8 Bit PWM gegangen, sondern nur auf 6 Bit. 
Reicht für diesen Anwendungszweck eigentlich aus, da ich keine 
LED-Fading Geschichten vor hatte.
Die 6-Bit machen sich nur bei der dunkelsten Einstellung bemerkbar. Der 
Sprung von Led ganz aus auf Led in der ersten Stufe gedimmt ist ein 
gewaltiger im Vergleich mit den anderen. Oder wenn man so will: Sterne, 
die wirklich nur gaaaaanz schwach leuchten lassen sich damit nicht 
machen.
Aber das war ja auch nicht das Ziel.

[Alex W. (a20q90)]

Habt ihr meinen Post eigendlich gelesen?

Ich habe dies geschrieben, weil ich dies schon gebaut habe!

[Karl H. (kbuchegg)]

Alex W. schrieb:
> Habt ihr meinen Post eigendlich gelesen?
>
> Ich habe dies geschrieben, weil ich dies schon gebaut habe!

Dann komm doch mit Details rüber.
Die Aussage: Ich habe das gemacht, ist zwar schön, hilft aber dem 
Fragesteller nichts.

[Gerd V. (gerald)]

Mit dem AVR (ATmega162) kann man locker 1400 LED's steuern!
Mein System läuft problemlos.
Helligkeit und Symbole sind per Software jederzeit änderbar.

[babble (Gast)]

Hallo zusammen,
Danke erst mal ich bin total begeistert für so schnelle und gute 
Antworten. Auf dem Gebiet Programmieren bin ich Anfänger und werde etwas 
länger brauchen um den Code durch zu arbeiten, aber auf den ersten blick 
versehe ich den Ablauf.

Vielen Dank babble

[attiny (Gast)]

ich habe mit attiny10 über 100 LEDs gesteuert. Hat ganz prima 
funktioniert.

[Fabian B. (fabs)]

Man Man, alle die so riesige Zahlen an LEDs mit ihren µCs ansteuern 
mögen doch bitte mit etwas mehr Info rüberkommen... wenn's machbar ist, 
möchte man dazu lernen, wenn nicht, lasst das Getöne. Aber ein "Ich hab 
aber nen Grösseren..." ist wenig informativ.

Anbei nochmal der Original-Code von Karl Heinz und zwei Fotos meiner 
Umsetzung.

Gruß
Fabian

PS: Ja, heute würde ich's wohl anders umsetzen ;-)

[M. B. (Firma: TH Nürnberg) (ohmen)]

Für größere Projekte dieser Art würde ich Kunststofflichtwellenleiter 
(POF) nehmen. Sieben 1mm POF in eine 3mm Bohrung und auf der anderen 
Seite eine 3mm LED rein. Schon hat man 7 mal mehr Pixel oder 7 mal 
weniger LED.
Das erkauft man sich allerdings dadurch, das diese sieben Pixel gleich 
leuchten, von daher eher was für größere Sachen, wo man mehr Abstand 
zwischen die Pixel bekommt...

HTH

[Roman65536 (Gast)]

Hallo Zusammen,

die Idee mit dem 595 finde super gut. Ich frage mich nur ... koennte man 
das usi Universal serial interface verwenden um die daten raus zu 
schieben ?? so ala ...

unsigned char byte=0;
unsigned char offset=0;
...
for( i = 0; i < 8; ++i ) {
    // je nach PWM eine 0 oder eine 1 in das SR schieben
 for( bit=0; bit <8; bit++) {
    // output byte zusammen stellen 
    if( Intesity[offset++] < PWMCount )
          byte |= 1;  
         // ^^ nur die 1 setzen .. Byte ist schon 0 am anfang      
          byte =  byte << 1;
         // links schieben 
         }
         // raus damit 
    USI_DATA=byte;
         // bis zum naechsten mal.. musste dieses byte schon lange raus sein, bei full speed. 
     }
...

nur ne idee.. musste paar cycles hier und da sparen ..
lg roman

[Markus M. (adrock)]

Marko B. schrieb:
> Da gibts ein paar nette Chips von TI:
>
> 
http://focus.ti.com/paramsearch/docs/parametricsearch.tsp?family=analog&familyId=480&uiTemplateId=NODE_STRY_PGE_T
>
> Bis zu 24 PWM-Kanäle.

Ja, nur muss man die erstmal bekommen :-) Zumindest als PDIP ist das 
nicht so einfach...

Ciao...
Markus

[Falk B. (falk)]

@  Markus M. (adrock)

>>http://focus.ti.com/paramsearch/docs/parametricsea...
>> Bis zu 24 PWM-Kanäle.

>Ja, nur muss man die erstmal bekommen :-) Zumindest als PDIP ist das
>nicht so einfach...

Nimm einen AVR mega 16, dort kannst du per Soft-PWM problemlos 32 
Kanäle ansteuern. Der ist auch als DIL verfügbar.

MFg
Falk

[Roman65536 (Gast)]

Nachtrag... :)


habe selber fuer meine kids ein aehnliche Sternenhimmel gebaut 
resp.hinterbeleuchtetes sternen/planetten/sonne/mond/erde poster.
Die sterne laufen als 5 verschieden kanaele, auf ca. 60 leds (man sieht 
nicht, das diese zusammen blinken/leuchten/glimmern). Der Saturn hat 
eine leuchtenden Ring und und und.. im anhang ein video von den ersten 
tests ..
vorsicht .. ist gross ...


lg roman



PS: Fabian... ist ja wunder schoen ! was stoert dich den ??
PS2:  Karl heinz.. Super Code !

[Fabian B. (fabs)]

Ich würde z.B. Konstantstrom-Treiber statt den TPICs nehmen... die 
vielen Widerstände zu verlöten war eine irre Arbeit. Es gibt da schöne 
von ICs von Allegro mit 64 Ausgängen.
Evtl würde ich auch einige Sterne über POF realisieren, damit könnte man 
dann mit einfachen Mitteln die "Sterngrösse" etwas variieren.

Ausserdem würde ich die Software so anpassen, dass die Sterne etwas 
sanfter von einer auf die andere Helligkeitsstufe wechseln, aber dafür 
braucht man mehr Stufen also müsste man sich da noch was einfallen 
lassen...

Gruß
Fabian

[Vlad T. (vlad_tepesch)]

Roman65536 schrieb:
> Hallo Zusammen,
>
> die Idee mit dem 595 finde super gut. Ich frage mich nur ... koennte man
> das usi Universal serial interface verwenden um die daten raus zu
> schieben ??

Ja dazu gibts einen Artikel:
http://www.mikrocontroller.net/articles/AVR-Tutorial:_Schieberegister#Ansteuerung_per_SPI-Modul

[Ulf R. (roolf)]

Karl heinz Buchegger schrieb:

> Genau darum bin ich nicht auf 8 Bit PWM gegangen, sondern nur auf 6 Bit.
> Reicht für diesen Anwendungszweck eigentlich aus, da ich keine
> LED-Fading Geschichten vor hatte.
> Die 6-Bit machen sich nur bei der dunkelsten Einstellung bemerkbar. Der
> Sprung von Led ganz aus auf Led in der ersten Stufe gedimmt ist ein
> gewaltiger im Vergleich mit den anderen. Oder wenn man so will: Sterne,
> die wirklich nur gaaaaanz schwach leuchten lassen sich damit nicht
> machen.

Für einen linearen Helligkeitsverlauf braucht man ein exponentiell 
ansteigendes Tastverhältnis.

Was spricht gegen folgenden Ansatz:
- Timer im CTC-Modus
- Obergrenze beginnt mit OCRn = 1
- Bei jedem Überlaufinterrupt wird die Obergrenze (OCRn) z.B. um Faktor 
2 erhöht, ggf. wieder auf 1 zurücksetzen
- Bei 8-Bit-Timer haben wir also 8 unterschiedliche Interrupts, jeweils 
1,2,4,8,...,256 Zeiteinheiten nach dem vorhergehenden; die ganze Sequenz 
dauert 2^9-1 Einheiten
- LEDs werden vor dem Interrupt OCRn = 1 eingeschaltet und zu einem 
späteren Interrupt wieder ausgeschaltet. Sie brennen also - wie 
gewünscht - 1,3,7,15,...,2^(k+1)-1,... 511 von 511 Einheiten (mit 
k=1,...8).

Pro LED brauchen wir dazu im Speicher sogar nur k zu codieren, was in 3 
Bits geht, und können dennoch dieselbe Dynamik abdecken wie beim 
normalen 8-Bit-PWM. [Edit: Ein weiteres Bit wird für den Zustand AN/AUS 
gebraucht.]

Überschlagsrechnung: Wenns nicht flackern soll, sollte die Sequenz (512 
Einheiten) in 10ms durch sein (100Hz). Eine Einheit ist dann 20us, d.h. 
der Timer muss mit 20us hochzählen. Bei 12MHz ist das ungefähr ein 
Prescaler von f/256.

Bei Programmierung in Assembler haben wir also ca. 256 CPU-Takte für die 
erste Interruptroutine, die alle LEDs einschalten muss; die späteren 
Interrupts haben dann reichlich mehr Zeit.

[Ulf R. (roolf)]

Ulf Rolf schrieb:

> - Bei 8-Bit-Timer haben wir also 8 unterschiedliche Interrupts, jeweils
> 1,2,4,8,...,256 Zeiteinheiten nach dem vorhergehenden;

Korrektur: 1,2,4, ..., 2^k, ..., 128, 256 Einheiten (k=0,...,8) sind 9 
unterschiedliche Interrupts.

> - LEDs werden vor dem Interrupt OCRn = 1 eingeschaltet und zu einem
> späteren Interrupt wieder ausgeschaltet. Sie brennen also - wie
> gewünscht - 1,3,7,15,...,2^(k+1)-1,... 511 von 511 Einheiten (mit
> k=1,...8).

Korrektur: k = 0,..., 8

> Überschlagsrechnung: Wenns nicht flackern soll, sollte die Sequenz (512
> Einheiten) in 10ms durch sein (100Hz). Eine Einheit ist dann 20us, d.h.
> der Timer muss mit 20us hochzählen. Bei 12MHz ist das ungefähr ein
> Prescaler von f/256.

Wir brauchen nun für die 9 verschiedenen Ein-Zustände definitiv 4 Bit 
Speicher, haben aber eine Dynamik von 1:511, also größer als bei einer 
klassischen 8-Bit-PWM.

Wahrscheinlich ist immer noch ein Rechenfehler drin?

[Alex H. (Gast)]

Hej,
bin selber gerade drann einen Sternenhimmel zu basteln.
Habe jetzt einen Code fertig. (Version 0.5)
Der Code selbst ist mit der Brechstange programmiert.
Also viel "If-Then-Else-Arbeit", aber er erfüllt seinen Zweck.

Ich habe ihn auf einem AtMega128 @16Mhz laufen.
Genutzt werden PortA/B/C/D und Timer1

Daraus ergeben sich 30 Kanäle und somit ein recht "zufälliges" 
Sternenbild
Zum Ablauf des Programms (etwa 4:10 Minuten):
 - Erst werden die Ports getestet (alle AN alle AUS)
 - Funkeln der Sterne (einige dimmen AUF andere dimmen AB)
 - Standbild
 - Blitze auf PortD
 - Neustart

Da der Code noch sehr... naja nicht so toll ist habe ich erstmal nur
die HEX angehangen.

Wenn der Code einer Veröffentlichung würdig ist werde ich ihn noch 
hochladen.
Wem es egal ist wie der Code aussieht^^ der kann sich bei mir per Mail 
melden. ([e-mail])

Groetjes
Alex

[Alex H. (Gast)]

Hej,
Hier die neue Version von heute Nacht.

Jetzt mit random()^^

WICHITG: Es wird PortE genutzt um anzuzeigen welches Programm gerade 
läuft.
 - PortE.0 = twinkel (slow)
 - PortE.1 = twinkel (medi)
 - PortE.2 = twinkel (fast)
 - PortE.3 = flash
 - PortE.4 = Standbild

Es gibt 5 Programme:
 - Auf und Abdimmen mit Sternblitzen (langsam)
 - Auf und Abdimmen mit Sternblitzen (mittel)
 - Auf und Abdimmen mit Sternblitzen (schnell)
 - Flash, d.h. Blitzen auf PortD
 - Pause, d.h. Sternenhelligkeit wird nicht mehr geändert

Alle Programme haben eine unterschiedliche Laufzeit und durch Random und 
vorgegebene Werte jeweils eine andere Dauer sowie Häufigkeit.

Das heißt "zufällige" Dauer und Wiedergabe der einzelnen Programme.
Wobei das Blitzen auf PortD nur sehr selten und kurz ist.
Aber langsames Faden und Standbild sehr lange und häufig vorkommen.


Hoffe euch gefällts auch wenn der CODE RIEEESIG ist^^

Liebe Grüße
Alex

[Alex H. (Gast)]

Hier ohne PortE für "< AtMega128"

[Karl H. (kbuchegg)]

Was soll das bringen, jetzt 100-tausend HEX-Files zu veröffentlichen?
Höchst wahrscheinlich hat sowieso niemand die exakt gleiche Hardware, 
die du hast. Das fängt beim Quarz an und hört bei der Portbeschaltung 
auf.

Wenn du etwas veröffentlichen willst, dann veröffentliche den Quellcode. 
Alles andere ist ziemlich sinnfrei in einem Forum wie diesem.

[Alex H. (Gast)]

Hej Karl Heinz Buchenegger,
Ich werde es auch dabei belassen, bis zu finalen Version.
Das Hexfile lässt sich auch bei anderer Hardware brennen, das Quarz 
verlangsamt hier nur die Updates, und die Ports sind ab Werk bei den 
AtMegas an der gleichen stelle.

Ich kann diese Beiträge nicht mehr editieren, sonst hätte ich im Ersten 
einfach alles aktuell gehalten.(so dass nur ein Beitrag und drei HEX 
vorhanden wären)
Zum Code habe ich ja gesagt er kommt... wenn er "schöner" ist, bis dahin 
können aber alle Suchenden schonmal den Himmel leuchten lassen.

Aber danke für deinen Hinweis
Gruß
Alex

[Karl H. (kbuchegg)]

Alex H. schrieb:

> Das Hexfile lässt sich auch bei anderer Hardware brennen, das Quarz

der Quarz

> verlangsamt hier nur die Updates, und die Ports sind ab Werk bei den
> AtMegas an der gleichen stelle.

Ach.
Und die AtMegas haben auch alle einen Treibertransistor bzw. einen 
ULN2803 als Treiber eingebaut. Und wenn ich meine LED gegen Vcc 
geschaltet habe und nicht gegen GND etc etc.

[Udo. R. S. (Gast)]

naja Patent pending...
Da hat vieleicht jemand Angst vor dem Diebstahl geistiger Werte :-)

[Alex H. (Gast)]

Hej Leute,
Wusste nicht das der Thread
"Machbarkeit - LED-Sternenhimmel mit AVR?"

Jetzt zur phylosophischen Diskussionsplattform metamorphieren soll.
Ich möchte die heiße Diskussion auch nur ungern hier austragen.

Der/Die/Das Nutella, sind wir schon so weit, sich gegenseitig auf 
Rechtschreibfehler zu dezimieren? Meinetwegen stürzt euch nur drauf^^

Treiber habe ich auch keine^^, geht auch so!
Jeder der da mitm AtMega rumbastelt weiß entweder wie man die Ports 
gegen GND zieht oder kann sich da was einfallen lassen.

War es nicht früher sogar gang und gäbe HEX-Files zu veröffentlichen und 
in EPROMMs zu brennen... ohne CODE???

Seit nicht einmal 24 Stunden konnten auch scheibar schon 8 Leute die HEX 
brauchen... damit wären diesen 8 doch schon geholfen und ist das hier 
nicht das Ziel???

Anderen helfen???


Nochmal gerade als Moderator. Wir sind doch in einem Fachforum.
Ich wollte lediglich...


Naja ich merke gerade, es würde nichts bringen weiter zu schreiben.

Ich lass es und lade keine HEX mehr hoch.
Danke für deinen Hinweis, sollte auch mehr ne Hilfe als eine Last sein.

@Udo. R. S.
So "toll" ist der Code nicht, es ist daher mehr ein Schutz als die Angst 
vor geistigem Diebstahl. Wie in meinem ersten Post bereits geschrieben: 
Bei interesse reicht ne Mail.

@ Alle anderen
Wer zukünfig vielleicht doch noch n HEX-File oder Code von mir haben 
will... schreibt per Mail. Helfe gerne wenn ich kann!

Sorry daher nochmal für die "Unannehmlichkeiten"

Euch allen aber noch fröhliche Weihnachten
Alex

----------------------------------------------
Wer Rehcdschriebfheler finted darv Sie gern behalden^^
Sie vermähren sich in Grupenhahltung