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
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.
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.
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
> 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.
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
....
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.
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
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
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
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)
1
#define SR_PORT PORTB
2
#define SR_DATA PB0 // Dateneingang vom Schieberegister SER
3
#define SR_CLOCK PB1 // Clock Eingang vom Schieberegister SCK
4
#define SR_STROBE PB2 // Datenübernahme im Schieberegister RCK
5
6
unsignedcharIntensity[64];
7
unsignedcharPWMCount;
8
9
ISR(TIMER2_OVF_vect)
10
{
11
unsignedchari;
12
13
PWMCount++;
14
if(PWMCount==64)
15
PWMCount=0;
16
17
for(i=0;i<64;++i){
18
// je nach PWM eine 0 oder eine 1 in das SR schieben
19
if(Intesity[i]>PWMCount)
20
SR_PORT&=~(1<<SR_DATA);
21
else
22
SR_PORT|=(1<<SR_DATA);
23
SR_PORT|=(1<<SR_CLOCK);
24
SR_PORT&=~(1<<SR_CLOCK);
25
}
26
27
SR_PORT|=(1<<SR_STROBE);
28
SR_PORT&=~(1<<SR_STROBE);
29
}
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.
1
intmain()
2
{
3
// Timer konfig
4
// ...
5
6
7
sei();// ab jetzt laufen die LED
8
9
for(i=0;i<64;++i)
10
Intensity[i]=i;
11
12
while(1)
13
;
14
}
Das sollte die LEDS unterschiedlich hell einschalten. Jede der 64 mit
einer anderen Intensität.
Darüber liegt dann noch eine 2-te Zeitsteuerung.
Wenn ich mich recht erinnere, habe ich mir fü jede LED eine Struktur
zurechtgelegt
1
structledData
2
{
3
unsignedcharIntensity;
4
unsignedcharItensityDunkel;
5
intHellTime;
6
intTime;
7
};
8
9
intBaseIntensHell;
10
intRandIntensHell;
11
longBaseTimeHell;
12
intRandTimeHell;
13
intBaseIntensDunkel;
14
intRandIntensDunkel;
15
longBaseTimeDunkel;
16
intRandTimeDunkel;
17
18
19
structledDataLedData[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
1
ISR(TIMER2_OVF_vect)
2
{
3
unsignedchari;
4
5
PWMCount++;
6
if(PWMCount==64)
7
PWMCount=0;
8
9
for(i=0;i<64;++i){
10
// je nach PWM eine 0 oder eine 1 in das SR schieben
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
1
ISR(TIMER2_OVF_vect)
2
{
3
unsignedchari;
4
5
PWMCount++;
6
if(PWMCount==64)
7
PWMCount=0;
8
9
for(i=0;i<64;++i){
10
// je nach PWM eine 0 oder eine 1 in das SR schieben
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.
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
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.
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?)
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!
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
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. 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.
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
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 ;-)
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
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 ...
1
unsigned char byte=0;
2
unsigned char offset=0;
3
...
4
for( i = 0; i < 8; ++i ) {
5
// je nach PWM eine 0 oder eine 1 in das SR schieben
6
for( bit=0; bit <8; bit++) {
7
// output byte zusammen stellen
8
if( Intesity[offset++] < PWMCount )
9
byte |= 1;
10
// ^^ nur die 1 setzen .. Byte ist schon 0 am anfang
11
byte = byte << 1;
12
// links schieben
13
}
14
// raus damit
15
USI_DATA=byte;
16
// bis zum naechsten mal.. musste dieses byte schon lange raus sein, bei full speed.
17
}
18
...
nur ne idee.. musste paar cycles hier und da sparen ..
lg roman
@ 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
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 !
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
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 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?
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. (alex.hoehfeld@gmx.de)
Groetjes
Alex
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
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.
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
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.
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