Strona 4 z 4

: niedziela 20 gru 2009, 20:21
autor: Pyra
Saul pisze: Pyra, dziękuję za podpowiedź z tymi drucikami. Takie proste rozwiązania jakoś mi do głowy przychodzą jako ostatnie :-|

No nie ma sprawy, sam wiem, że najprostsze rzeczy na końcu wpadają do głowy ;)
Saul pisze:Na początku wygląda to tak:
0,0,255,255,255,0,0,0|0,0,0,0,0,0,0,0|0,0,0,0,0,0,0,0|0,0,0,0,0,0,0,0|0,0,0,0,0,0,0,0
Trzy "diody" zapalone, ale poza obszarem widzialnym.
Teraz w pętli zaczynam sprawdzać od początku kolejne bajty. Jeśli = 0 to sprawdzam kolejny. Jeśli różny od 0 to robię jemu przesunięcie bitowe w prawo i wstawiam w to samo miejsce. Następnie w kolejne dwa bajty wstawiam 255, a w następny wstawiam ten pierwszy bajt, na którym robiłem przesunięcie bitowe, z tym że w postaci zanegowanego odbicia lustrzanego. Tak bitowo wygląda cała sekwencja:

11111111,11111111,11111111,00000000
01111111,11111111,11111111,00000001
00111111,11111111,11111111,00000011
00011111,11111111,11111111,00000111
00001111,11111111,11111111,00001111
00000111,11111111,11111111,00011111
00000011,11111111,11111111,00111111
00000001,11111111,11111111,01111111
00000000,11111111,11111111,11111111

i tak w kółko, aż śnieżynka nie spadnie w obszar pamięci nie odwzorowanej na diodach. Algorytm pewnie niezbyt wyszukany, ale taki obmyśliłem :lol:
Czyli 1 bajt reprezentuje jasność pojedynczego LEDa, a ta jest wyrażona stosunkiem ilości zer do jedynek :roll:

Teraz zapalasz LEDa jeśli w kolejnym bicie jest 1 a nie zapalasz jeśli zero, czyli wyświetlanie jest w pętli 8 przebiegowej i po kolei obrazujesz bity wszystkich bajtów, uzyskując w ten sposób PWM 1:8. Sprytne, jeśli dobrze rozumuję :roll:

Co do bajtów startowych, to na początku też je chciałem umieszczać bezpośrednio w "niewidocznych" miejscach pamięci, ale potem stwierdziłem, że będę je robił na bieżąco w pętli, przez co zyskuję możliwość dowolnego kształtowania długości śnieżynki, tylko przez zmianę długości pętli.

Pozdrawiam

: niedziela 20 gru 2009, 23:02
autor: swietlik
Saul pisze: W tej chwili moje rozwiązanie wygląda tak, że mam zarezerwowane 40 bajtów w pamięci. Bajty od 8 do 32 odpowiadają jasności kolejnych 24 LEDów. Jeśli jest 0 to dioda nie świeci, jeśli 255 to świeci na 100%. Pod spodem przykład. To co na niebiesko to widzimy na diodach. Na początku wygląda to tak:
0,0,255,255,255,0,0,0|0,0,0,0,0,0,0,0|0,0,0,0,0,0,0,0|0,0,0,0,0,0,0,0|0,0,0,0,0,0,0,0
Trzy "diody" zapalone, ale poza obszarem widzialnym.
Teraz w pętli zaczynam sprawdzać od początku kolejne bajty. Jeśli = 0 to sprawdzam kolejny. Jeśli różny od 0 to robię jemu przesunięcie bitowe w prawo i wstawiam w to samo miejsce. Następnie w kolejne dwa bajty wstawiam 255, a w następny wstawiam ten pierwszy bajt, na którym robiłem przesunięcie bitowe, z tym że w postaci zanegowanego odbicia lustrzanego. Tak bitowo wygląda cała sekwencja:

11111111,11111111,11111111,00000000
01111111,11111111,11111111,00000001
00111111,11111111,11111111,00000011
00011111,11111111,11111111,00000111
00001111,11111111,11111111,00001111
00000111,11111111,11111111,00011111
00000011,11111111,11111111,00111111
00000001,11111111,11111111,01111111
00000000,11111111,11111111,11111111
Czyli, jeśli dobrze zrozumiałem, równie dobrze mógłbyś mieć sekwencję początkową:

0,255,0,0,0,0,0,0 | 0,0,0,0,0,0,0,0 | .....

i też algorytm przy pierwszym przebiegu powinien to rozwinąć do:

0, 127, 255, 255, 1, 0, 0, 0, 0 | .......

i dalej już według tego co napisałeś?

Czy z tego wynika, że w opisanym przykładzie na raz nie świecą więcej niż 4 diody, z czego dwie środkowe zawsze na 100%?

A wyświetlanie? Tak jak myśli Pyra? Przemiatasz taką sekwencję bajtów

00011111,11111111,11111111,00000111

osiem razy, testując każdy bit?

LED_ON = (bajt[led] & (1<< nr_przebiegu_petli)) ?

: niedziela 20 gru 2009, 23:39
autor: Saul
swietlik pisze:Czy z tego wynika, że w opisanym przykładzie na raz nie świeci więcej niż 4 diody, z czego dwie środkowe zawsze na 100%?
Dokładnie tak.
swietlik pisze:Czyli, jeśli dobrze zrozumiałem, równie dobrze mógłbyś mieć sekwencję początkową:
0,255,0,0,0,0,0,0 | 0,0,0,0,0,0,0,0 | .....
i też algorytm przy pierwszym przebiegu powinien to rozwinąć do:
0, 127, 255, 255, 1, 0, 0, 0, 0 | .......
i dalej już według tego co napisałeś?
Zgadza się. :-) Mógłbym nawet zamiast pojedynczego 255 jak podałeś, wstawić 1.
0,1,0,0,0,0,0,0 | 0,0,0,0,0,0,0,0 | .....
Wtedy po pierwszym przejściu wyszłoby:
0,0,255,255,255,0,0,0 | 0,0,0,0,0,0,0,0 | .....
Przy kolejnym:
0,0,127,255,255,1,0,0 | 0,0,0,0,0,0,0,0 | .....
itd.
Procedurka banalna, a ruch się sam nakręca :-) Długość śnieżynki to wiadomo... zwiększam lub zmniejszam ilość 255 w środku.

Jeśli chodzi o PWM to niestety nie jest taki sprytny jak myślał Pyra. Zwykły programowy 0-255. W pętli od 0 do 255 na starcie zapalam wszystkie LEDy, a następnie z tablicy odczytuję wartość wypełnienia dla każdej diody i sprawdzam czy jest równa z licznikiem. Jeśli jest to wyłączam diodę. Czyli praktycznie mógłbym zrobić płynne rozjaśnianie i przygaszanie, a nie tylko w 8 krokach. Zamiast dzielenia przez 2 mógłbym po prostu odejmować 1 i to działa, procek się wyrabia, ale przy takim ruchu nie daje to wrażenia jeszcze większej płynności, więc z tego zrezygnowałem. Poza tym przy odejmowaniu spadek jasności nie następował liniowo, a przy dzieleniu jest w miarę równo we wszystkich krokach i to zaważyło.

Oczywiście w międzyczasie realizowane jest multipleksowanie na trzech modułach (moduł czyli 8 diod). Choć teraz doszedłem do wniosku, że to bez sensu i wystarczyło by zrobić multipleks na 2 modułach bo przecież dla ilości naraz zapalonych LEDów <8 nie potrzeba więcej niż 2 naraz multipleksowane moduły. I tylko w miarę spadania odcinać ostatni "wygaszony" moduł i załączać kolejny z przodu.

: poniedziałek 21 gru 2009, 06:09
autor: Pyra
Saul pisze: Jeśli chodzi o PWM to niestety nie jest taki sprytny jak myślał Pyra. Zwykły programowy 0-255. W pętli od 0 do 255 na starcie zapalam wszystkie LEDy, a następnie z tablicy odczytuję wartość wypełnienia dla każdej diody i sprawdzam czy jest równa z licznikiem. Jeśli jest to wyłączam diodę. Czyli praktycznie mógłbym zrobić płynne rozjaśnianie i przygaszanie, a nie tylko w 8 krokach. Zamiast dzielenia przez 2 mógłbym po prostu odejmować 1 i to działa, procek się wyrabia, ale przy takim ruchu nie daje to wrażenia jeszcze większej płynności, więc z tego zrezygnowałem. Poza tym przy odejmowaniu spadek jasności nie następował liniowo, a przy dzieleniu jest w miarę równo we wszystkich krokach i to zaważyło.
Ja tez zauważyłem, że 2 stopnie trochę mało, zostałem na 4, stwierdziłem, że dalsze zwiększanie nic nie daje.... Co do liniowości to df kiedyś mi podrzucił algorytm, właśnie z przesuwaniem bitów.
Saul pisze:Oczywiście w międzyczasie realizowane jest multipleksowanie na trzech modułach (moduł czyli 8 diod). Choć teraz doszedłem do wniosku, że to bez sensu i wystarczyło by zrobić multipleks na 2 modułach bo przecież dla ilości naraz zapalonych LEDów <8 nie potrzeba więcej niż 2 naraz multipleksowane moduły. I tylko w miarę spadania odcinać ostatni "wygaszony" moduł i załączać kolejny z przodu.
Też się zastanawiałem nad wyłączaniem nieczynnych segmentów, tyle, że miało by to sens dopiero przy większej ilości LEDów. Dla 3 segmentów jest jeszcze OK bez tego.
Można by to zrobić powtarzając sekwencję przesuwania dla kolejnych 16 LED. Zacząć od pierwszych 8, po przejściu zapalonej części do drugiej 8, następował by przerzut jej do pierwszej i zmiana nr segmentów o 1.
Czyli
segment 1 i 2
B1...............B2
01111000 00000000
00000111 10000000
00000001 11110000
00000000 11110000
przerzut
B1 = B2
B2 = 0
segment 2 i 3
B1...............B2
11110000 00000000
00001111 00000000
00000011 11000000
00000000 11110000
przerzut
B1 = B2
B2 = 0
segment 3 i 4.......

Ograniczył bym się jednak do multipleksowania dwóch modułów, bo wtedy jasność względna była by stała. Gdyby multipleksowanie rozszerzyć na 1 lub 2 moduły wtedy byśmy mieli wypełnienie 100% i 50% w zależności od ilości czynnych modułów.

Pozdrawiam

: wtorek 22 gru 2009, 14:36
autor: swietlik
Pyra pisze:
swietlik pisze:
ale to co zaproponowałeś jest jeszcze elastyczniejsze. Mam zmodyfikować generator w C? :)
Jeśli masz ochotę, to czemu nie ;) Ja i tak będę robił w BASCOMie, ale muszę znaleźć trochę wolnego czasu :roll:
No to zrobiłem, może się komuś przyda. A do języka C namawiam, po asemblerze to chyba drugi w kolejności język pod względem precyzji kontroli nad tym, co robi mikrokontroler.

Modyfikacja funkcji snowfall():

Kod: Zaznacz cały

void snowfall&#40;void&#41;
&#123;
	while&#40;1&#41; &#123;					// a snieg pada i pada i pada ...
		u1.bity = u2.bity = 0xffff;

		for&#40;int cykl = 0; cykl <= CYKLE; ++cykl&#41; &#123;
			if &#40;cykl == 0&#41; &#123;
				u1.bity <<= 1;
			&#125;
			if &#40;cykl > 0 && cykl <= DIODY&#41; &#123;
				u1.bity <<= 1;
				u2.bity <<= 1;
			&#125;
			if &#40;cykl == DIODY+1&#41; &#123;
				u1.bity <<= 1;
				u1.bity += 1;
				u2.bity <<= 1;
			&#125;
			if &#40;cykl > DIODY+1&#41; &#123;
				u1.bity <<= 1;
				u1.bity += 1;
				u2.bity <<= 1;
				u2.bity += 1;
			&#125;

			wyswietl&#40;&#41;;
		&#125;

		sleep&#40;random&#40;20&#41;&#41;; // drzemka po każdym cyklu
	&#125;
	return;
&#125;
i wynik działania:

Kod: Zaznacz cały

u1&#91;1,0&#93;=11111111|11111110 u2&#91;1,0&#93;=11111111|11111111
u1&#91;1,0&#93;=11111111|11111100 u2&#91;1,0&#93;=11111111|11111110
u1&#91;1,0&#93;=11111111|11111000 u2&#91;1,0&#93;=11111111|11111100
u1&#91;1,0&#93;=11111111|11110000 u2&#91;1,0&#93;=11111111|11111000
u1&#91;1,0&#93;=11111111|11100000 u2&#91;1,0&#93;=11111111|11110000
u1&#91;1,0&#93;=11111111|11000001 u2&#91;1,0&#93;=11111111|11100000
u1&#91;1,0&#93;=11111111|10000011 u2&#91;1,0&#93;=11111111|11000001
u1&#91;1,0&#93;=11111111|00000111 u2&#91;1,0&#93;=11111111|10000011
u1&#91;1,0&#93;=11111110|00001111 u2&#91;1,0&#93;=11111111|00000111
u1&#91;1,0&#93;=11111100|00011111 u2&#91;1,0&#93;=11111110|00001111
u1&#91;1,0&#93;=11111000|00111111 u2&#91;1,0&#93;=11111100|00011111
u1&#91;1,0&#93;=11110000|01111111 u2&#91;1,0&#93;=11111000|00111111
u1&#91;1,0&#93;=11100000|11111111 u2&#91;1,0&#93;=11110000|01111111
u1&#91;1,0&#93;=11000001|11111111 u2&#91;1,0&#93;=11100000|11111111
u1&#91;1,0&#93;=10000011|11111111 u2&#91;1,0&#93;=11000001|11111111
u1&#91;1,0&#93;=00000111|11111111 u2&#91;1,0&#93;=10000011|11111111
u1&#91;1,0&#93;=00001111|11111111 u2&#91;1,0&#93;=00000111|11111111
u1&#91;1,0&#93;=00011111|11111111 u2&#91;1,0&#93;=00001111|11111111
u1&#91;1,0&#93;=00111111|11111111 u2&#91;1,0&#93;=00011111|11111111
u1&#91;1,0&#93;=01111111|11111111 u2&#91;1,0&#93;=00111111|11111111
u1&#91;1,0&#93;=11111111|11111111 u2&#91;1,0&#93;=01111111|11111111
u1&#91;1,0&#93;=11111111|11111111 u2&#91;1,0&#93;=11111111|11111111
Myślę jeszcze nad kodem dla algorytmu użytego przez Saula, ale zakodowanego nieco oszczędniej. Jeden bajt na jedną diodę to w warunkach mikrokontrolera trochę rozrzutnie ;-)

: czwartek 31 gru 2009, 20:54
autor: ixjakub
A ode mnie za darmo wygaszacz ekranu o nazwie SnowFall. Powinien działać w różnych rozdzielczościach. Do pobrania tu:
http://w915.wrzuta.pl/sr/f/6ZOe6fyvR5K/snowfall1360
Tak to wygląda:
Obrazek
Wyłączamy klawiszem Esc.

:cool:

edit:
A tu zegarek ze SnowFallem:
http://w913.wrzuta.pl/sr/f/4KAo1XVmzjq/ ... 1_snowfall
Obrazek
edit2:
Poprawiony, na 100% działa.
http://w913.wrzuta.pl/sr/f/4KAo1XVmzjq/ ... 1_snowfall
:mrgreen:

: piątek 01 sty 2010, 00:14
autor: Darek
A w tym wygaszaczu z zegarkiem jest data 01:00:2010 cos nie tak jak na mój gust :)

[ Dodano: Pią Sty 01, 2010 12:15 am ]
I wszystkiego najlepszego z Nowym Rokiem

: piątek 01 sty 2010, 20:54
autor: ixjakub

: piątek 01 sty 2010, 21:37
autor: Darek
O teraz jest OK

: piątek 06 sty 2012, 14:29
autor: Andrzej77
Jako nowy witam wszystkich użytkowników i pozdrawiam z pomorza zachodniego!

Zaczytuję się w Waszych postach, podziwiam pomysły i zazdroszczę wiedzy. Nie jestem aż tak wyszkolony, ale jakąś wiedzę mam i potrafię conieco stworzyć ze schematów.
Odświeżam temat, bo napatrzyłem się na takie sople w Berlinie i też takie chcę! Ceny gotowych zwalają z nóg, albo są za krótkie. Więc może sklecić coś takiego, na podstawie projektu kolegi Saula. Ten schemat, który załączył chcę rozbudować o kolejny zestaw 8 ledów, tak do 32 szt. (podobno pociągnie).
Nie wiem tylko jakim prądem zasilać ten projekt. Napięcie 5V. OK. Co z natężeniem przy zastosowaniu standardowych ledów 20mA?
Przerażają mnie również te wszystkie zero-jedynkowe rozpiski :shock: . Czy powinno to mieć dla mnie jakieś znaczenie? Czy w tym pojekcie należy cokolwiek programować? Czy jest to tylko informacja, w jakich konfiguracjach układ pracuje.
Czy taki projekt wystarczy polutować i podłączyć? I ma latać? Bo jeśli trzeba cokolwiek w jakikolwiek sposób programować, to... ponad moje siły (wiedzę). Co z tranzystorami: PNP (jak ktoś sugerował) czy NPN (jak na schemacie).
To jak? Pomożecie?

: piątek 06 sty 2012, 16:13
autor: Pyra
Witam
Andrzej77 pisze:Czy w tym projekcie należy cokolwiek programować?
Musze Cię niestety rozczarować, ale całością steruje mikroprocesor, w zasadzie jeden na jeden sopel. Te zerojeynkowe rozpiski, to zasada sterowania jasnością LEDów, tak aby powstało złudzenie płynności ruchu. To stąd wynikają wysokie ceny gotowych produktów.

Pozdrawiam

: piątek 06 sty 2012, 17:20
autor: Andrzej77
A więc niestety tak... Czy mógłbyś kolego coś więcej na temat owego programowania. Jakieś linki, instrukcje.
Bo rozumiem, że śrubokrętem tego nie zrobię. Sorry, że zawracam głowę, ale najarałem się na to ustrojstwo.
Czym to się robi (jak sądzę komputer się przyda czy też inny programator). Jakiś program? Kabel? Czy laik (ale pojętny), jak ja jest w stanie to przeskoczyć, czy trzeba być jak Chuck Norris? Jeśli szukajka wystarczy, to jak znaleźć coś konketnego? Jeśli to temat rzeka, albo ocean nawet to spuść na to zasłonę milczenia :mrgreen: . Szkoda czasu i Twojego i mojego :wink:
Czy raczej zabrać się za Twój schemat, bardziej przyjazny. Tyle, że widzę tam tylko 6 ledów. Można toto rozbudować do wspomnianych 32 (jak?)? Czy szafa sterownicza do tego musiałaby być wielkości jelcza wtedy. Czy w Twoim projekcie osiągnąłeś ten sam efekt, co Saul? Jest na Twoim schemacie parę niedociągnięć (np. R1 idzie do nikąd). Mógłbyś podesłać mi na maila schemat źródłowy, bo mam wrażenie, że pomniejszanie obrazka pozbawiło go niektórych kresek.

: sobota 07 sty 2012, 11:23
autor: Pyra
Witam
Ja używam programatora STK 200, do tego środowisko BASCOM-AVR do pisania programów i programowania procków. Mój program jest dość prosty, i był tylko sprawdzeniem koncepcji schematu, Saul napisał bardziej rozbudowany, ale w innym języku.
Co do schematu analogowego, to efekt jest niestety niewspółmiernie gorszy od wersji na &#181;P. Rezystor R1 łączysz z ostatnim w szeregu segmentem, czyli w tym wypadku w miejsce połączenia R12 i R6.

Pozdrawiam

: sobota 10 sty 2015, 19:17
autor: swietlik
Odświeżę dawny temat.

Przed świętami pomyślałem, że dobrze by mieć choćby mini-śnieżynkę. Niestety, nie mam ostatnio prawie wcale czasu na zabawę ze światełkami :( ale.. miałem pod ręką Arduino Tiny (v3) i kilka diod i oporników, więc na szybko powstała wersja sześciodiodowa (tyle wyjść programowego PWM jest wspieranych na Tiny). Schemat jest banalny, diody anodą do wyjścia mikrokontrolera przez opornik 220R, a katodą do minusa zasilania. Kod sterujący tą miniaturką wygląda tak:

Kod: Zaznacz cały

// numery I/O z kolejnymi diodami
int LED1 = 3;
int LED2 = 5;
int LED3 = 6;
int LED4 = 9;
int LED5 = 10;
int LED6 = 11;


void setup&#40;&#41;
&#123;
  // konfiguracja I/O
  pinMode&#40;LED1, OUTPUT&#41;;
  pinMode&#40;LED2, OUTPUT&#41;;
  pinMode&#40;LED3, OUTPUT&#41;;
  pinMode&#40;LED4, OUTPUT&#41;;
  pinMode&#40;LED5, OUTPUT&#41;;
  pinMode&#40;LED6, OUTPUT&#41;;

  // stan początkowy - diody wyłączone
  digitalWrite&#40;LED1, 0&#41;;
  digitalWrite&#40;LED2, 0&#41;;
  digitalWrite&#40;LED3, 0&#41;;
  digitalWrite&#40;LED4, 0&#41;;
  digitalWrite&#40;LED5, 0&#41;;
  digitalWrite&#40;LED6, 0&#41;;
&#125;


void loop&#40;&#41;
&#123;
  
  int base_d = 40;  // bazowe opóźnienie
  int d = base_d;
  int k = 7;
  
  while&#40;1&#41; &#123;
    d = base_d + random&#40;40&#41;;  // modyfikacja prędkości opadania
    delay&#40;random&#40;500,5000&#41;&#41;;  // losowy odstęp między śnieżynkami

    analogWrite&#40;LED1, 16*k&#41;;
    delay&#40;d/4&#41;;
    
    analogWrite&#40;LED1, 32*k&#41;;
    delay&#40;d&#41;;
    
    analogWrite&#40;LED1, 16*k&#41;;
    analogWrite&#40;LED2, 32*k&#41;;
    analogWrite&#40;LED3, 8*k&#41;;
    delay&#40;d&#41;;
    
    analogWrite&#40;LED1, 8*k&#41;;
    analogWrite&#40;LED2, 16*k&#41;;
    analogWrite&#40;LED3, 32*k&#41;;
    analogWrite&#40;LED4, 8*k&#41;;
    delay&#40;d&#41;;
    
    analogWrite&#40;LED1, 0*k&#41;;
    analogWrite&#40;LED2, 8*k&#41;;
    analogWrite&#40;LED3, 16*k&#41;;
    analogWrite&#40;LED4, 32*k&#41;;
    analogWrite&#40;LED5, 8*k&#41;;
    delay&#40;d&#41;;
    
    analogWrite&#40;LED2, 4*k&#41;;
    analogWrite&#40;LED3, 8*k&#41;;
    analogWrite&#40;LED4, 16*k&#41;;
    analogWrite&#40;LED5, 32*k&#41;;
    analogWrite&#40;LED6, 8*k&#41;;
    delay&#40;d&#41;;
    
    analogWrite&#40;LED2, 0*k&#41;;
    analogWrite&#40;LED3, 4*k&#41;;
    analogWrite&#40;LED4, 8*k&#41;;
    analogWrite&#40;LED5, 16*k&#41;;
    analogWrite&#40;LED6, 32*k&#41;;
    delay&#40;d&#41;;
    
    analogWrite&#40;LED3, 2*k&#41;;
    analogWrite&#40;LED4, 4*k&#41;;
    analogWrite&#40;LED5, 8*k&#41;;
    analogWrite&#40;LED6, 16*k&#41;;
    delay&#40;d&#41;;
    
    analogWrite&#40;LED3, 0*k&#41;;
    analogWrite&#40;LED4, 2*k&#41;;
    analogWrite&#40;LED5, 4*k&#41;;
    analogWrite&#40;LED6, 8*k&#41;;
    delay&#40;d&#41;;
    
    analogWrite&#40;LED4, 0*k&#41;;
    analogWrite&#40;LED5, 2*k&#41;;
    analogWrite&#40;LED6, 4*k&#41;;
    delay&#40;d&#41;;
    
    analogWrite&#40;LED5, 0*k&#41;;
    analogWrite&#40;LED6, 2*k&#41;;
    delay&#40;d&#41;;
    
    analogWrite&#40;LED6, 0*k&#41;;   
  &#125;  
&#125;

Jako że jestem starej daty inżynierem, nazewnictwo stosowane w środowisku Arduino mnie odrzuca ('Analog' zamiast PWM, różne 'shieldy' zamiast płytek rozszerzeń itp.) ale jest jak jest, takie nazewnictwo się przyjęło i tyle. Kod działa, śnieżynki spadają i to najważniejsze :)