Kentsel napisał(a):
Wygląda mi to na fragment kodu z innej led cube.
Nie, to nie jest fragment gotowego kodu, to moja propozycja napisana według Twojego opisu.
Kentsel napisał(a):
Nie zależy mi na oszczędności pamięci...
Kiedyś przeglądałem "gotowce", ale nie korzystałem, bo raz że zmieniłem schemat troszkę, włożyłem inne kości do multipleksowania
To nie tylko kwestia oszczędności pamięci. Większość operacji na tablicy 512 elementowej będzie trwała zdecydowanie dłużej.
Moja propozycja to tablica 8x8. Wymiary tablicy to osie x i y. Każdy bajt w tablicy reprezentuje 8 diod w osi z. Oczywiście nazewnictwo osi to kwestia umowna, można zmienić kolejność wedle uznania.
Nie wiem jak to multipleksujesz, myślę jednak, że organizacja tablicy nie ma na to większego wpływu. Podejrzewam nawet, że moja propozycja działałaby szybciej, ponieważ łatwiej odczytać 64 bajty (gotowe całe rzędy diod w jednym bajcie) niż odczytywać 512 bajtów i z każdego wydobywać 1 bit. Sama kalkulacja adresu tablicy trójwymiarowej będzie trwała dłużej, a trzeba to przemnożyć przez ilość odczytywanych bajtów.
Kentsel napisał(a):
Musi być dokładnie 64 elementów (jedynek) rozstrzelonych na całą objętość kostki, ale nie powtarzających się elementów, coś na wzór sudoku(mi to się z tym kojarzy). Miliony godzin, pętli i warunków i albo generuje śmieci, albo pętla losująca się zatrzymuje i program staje...
Gdyby zrobić listę dostępnych współrzędnych, każdy piksel wylosowany musiałby od razu blokować 7 innych, a ja już kompletnie nie wiem jak to ugryźć...
Czasem przy problemach z losowanie dodawałem do pętli flagę, warunek o przepełnieniu do while i potem jakiś debug, ale tu debug i przypisywanie elementów na sztywno to nie to co chcę osiągnąć....
Właśnie problem w tym, że w taki sposób - jak sam zauważyłeś - trudno będzie Ci osiągnąć cel.
Próbowałem podsunąć następujące rozwiązanie - nieco odmienne podejście. Wyobraźmy sobie ścianę kostki x-y jako 64 elementy (8x8). Każdy element zawiera liczbę, która jest numerem (identyfikatorem) diody która się świeci w osi z.
Jeśli teraz utworzymy takie Twoje sudoku:
Code:
x
0 1 2 3 4 5 6 7
1 2 3 4 5 6 7 0
2 3 4 5 6 7 0 1
y 3 4 5 6 7 0 1 2
4 5 6 7 0 1 2 3
5 6 7 0 1 2 3 4
6 7 0 1 2 3 4 5
7 0 1 2 3 4 5 6
to mamy pewność, że patrząc na dowolną płaszczyznę będziemy widzieć 64 diody pokrywające całą płaszczyznę, po jednej pod każdą współrzędną danej płaszczyzny.
Ten wzór jest jednak regularny, a nie o to chodzi. Przyjmijmy jednak to za pozycję wyjściową. Jeśli teraz spróbujemy zrobić tak:
Code:
zamieniamy 2 losowe wiersze
pomiędzy sobą
x
0 1 2 3 4 5 6 7
5 6 7 0 1 2 3 4
2 3 4 5 6 7 0 1
y 3 4 5 6 7 0 1 2
4 5 6 7 0 1 2 3
1 2 3 4 5 6 7 0
6 7 0 1 2 3 4 5
7 0 1 2 3 4 5 6
a później 2 losowe kolumny
x
0 6 2 3 4 5 1 7
5 3 7 0 1 2 6 4
2 0 4 5 6 7 3 1
y 3 1 5 6 7 0 4 2
4 2 6 7 0 1 5 3
1 7 3 4 5 6 2 0
6 4 0 1 2 3 7 5
7 5 1 2 3 4 0 6
to już to wygląda trochę lepiej, a nadal zachowujemy odpowiednie relacje we wszystkich wierszach i kolumnach. Jeśli powtórzymy tę operację kilkadziesiąt razy stosując losowe numery wierszy i kolumn, uzyskamy przypadkową i niepowtarzalną kombinację cały czas zachowując założone reguły (jedna dioda w każdym rzędzie).
Warunkiem jest oczywiście uzyskanie naprawdę losowych liczb, bo w AVR to nie jest proste.
To co opisałem powyżej zrealizowałem w przedstawionym wcześniej kodzie na tablicy mojej konstrukcji. Na pewno da się to też zrealizować na Twojej tablicy, jednak będzie to trwało zdecydowanie dłużej. U mnie wygenerowanie tablicy przy 53 iteracjach pętli (być może wystarczy mniej, trzeba byłoby przetestować) trwało niecałe 12ms dla zegara 16MHz.
Mam nadzieję, że było zrozumiale i że koncepcja się przyda.
_________________
AVR-GCC - dane w pamięci FLASHStatystyki: Napisane przez andrews — 15 lis 2017, o 11:15
]]>
.
), to zrobienie tak: