Witam.
Napisałem program do kostki do gier na Attiny13.
Kod:

Założenie jest takie, że timer w trybie ctc liczy sobie z i zwiększa zmienna 'i'.
Gdy nacisnę przycisk, przerwanie PCINT ma wyliczyć zmienna 'liczba' ze wzoru '' liczba = ((i % 5) + 1) ''. Takie losowanie liczby z zakresu od 1 do 6
Schemat podłączenia diod jest następujący:

Problem to brak reakcji na przycisk i wyświetlanie losowo liczb na kostce.
Wie ktoś może dlaczego tak się dzieje?
Z góry dziękuję za zainteresowanie tematem.

Pozdrawiam: Piter3132!

Brakuje ustawienia 1 na PB3 i pull-up raczej używałbym tylko w odniesieniu do wejść, a w przypadku wyjść ustawienie.

Bardzo to jest brzydkie, bo nic nie mówi i źle działa, bo wyłącza pull-up przyciskowi. Popraw sobie na:

_________________
Dragonus Cracovus: Biomagia

Dziękuję za pokazanie błędów.
Nie wiem jak mogłem zrobić coś tak głupiego z tym wyłączaniem ledów
Układ teraz bardzo ładnie robi co ma robić

Jeszcze raz dziękuje i obiecuje poprawę

Z ciekawości złożyłem powyższy układ na stykówce i znalazłem jeszcze jeden błąd. Mianowicie nigdy nie uda się wylosować liczby o 6 oczkach.

Po zmianie:

na:

działa jak trzeba.

Poniżej moja wersja troszkę przerobiona, z użyciem switch zamiast if'ów.

Zrobiłem dokładnie to samo 5 minut po odkryciu błędów przez użytkownika Krauzer ale dzięki za chęć pomocy

Ostateczny kod wygląda tak:


Kod zajmuje 40% pamięci FLASH i 3,1% RAM'u tego małego klocka

No to super, że sobie tak świetnie poradziłeś. Sprawdziłem na swoim kodzie i wygląda to tak:

AVR Memory Usage
----------------
Device: attiny13

Program: 330 bytes (32.2% Full)
(.text + .data + .bootloader)

Data: 2 bytes (3.1% Full)
(.data + .bss + .noinit)

Oczywiście dla Attiny13.

Pewnie u ciebie zajmuje mniej bo zrobiłeś funkcję przywolywana po wyswietleniu liczby, a ja za kazdym razem używam delaya.
Zastosuję twoje rozwiązanie, trzeba się uczyć oszczędzania pamięci w prockach
Widzę, że mój pomysł z kostką się spodobał

Challenge accepted



Kto da mniej ;> bo jeszcze jest potencjał

(testowane w układzie na kolanie, ale wygląda na to, że działa ok)

Niezle!

A moze tak:

Device: attiny13

Program: 184 bytes (18.0% Full)
(.text + .data + .bootloader)

Data: 1 bytes (1.6% Full)
(.data + .bss + .noinit)

Bedzie dzialac?

Ale was to wzięło

Wyścig o jak najmniejszy kod jest zabawny i pouczający ale proponuję zastanowić się nad czymś bardziej użytecznym Mianowicie nad zrezygnowaniem z pstryczka zasilania i utrzymywaniem procka w stanie uśpienia między losowaniami. Przyciśnięcie batona wybudza procek i losuje liczbę, który po wyświetleniu znów przechodzi w stan uśpienia.

_________________
+++++[>++++<-]>[>++++++<-]>.---------.+++.

I dodatkowo wszystko proszę napisać w asemblerze w ramach nauki

_________________
Pomysły na podpis - wyślij SMSa +1 769 243 0011

@anshar niestety - żeby działało z PROGMEM trzeba by odczytywać tablicę poprzez jakieś pgm_read... czy coś w tym stylu. Tak jak wrzuciłeś nie działa. Dodatkowo w opóźnieniu brakuje zerowania "j". Po zmianach:





Czyli i tak lepiej o 2B

@mokrowski - dla Ciebie zawsze ;d Część z proponowanych przez Ciebie zmian wymyśliłem już wcześniej (chociaż teraz pewnie nikt mi nie uwierzy). Tych na które nie wpadłem - nie śmiem sobie przypisywać. Tak czy siak: podbijam stawkę Kilka "dziwacznych" pomysłów:

1. wrzucenie zmiennej "i" do sekcji ".noinit" i ręczne wyzerowanie na początku main - w efekcie wylatuje kod startowy odpowiedzialny za zerowanie sekcji .bss -> z 202B flash'a (jako punkt wyjścia przyjąłem mój poprzedni kod) robi się 190B

2. własna tablica wektorów (dorzucone "-nostartfiles" do opcji linkera) - skrócona tylko do TIM0_COMP, bez funkcji "bad interrupt" -> z 190B robi się 176B

3. zmiana koncepcji: zmienna "i" przypisana do rejestru: 166B flash (0B sram)

Kod z powyższymi zmianami (zmieniłem nazwę zmiennej z "i" na dużo mówiące "zmienna" - "i" za mało rzucało się w oczy):



--------

4 - zupełna zmiana koncepcji - wyrzucenie przerwania od timera i wszystkiego co związane z przerwaniem licznika i przerwaniami ogólnie



Efekt:


Kostka działa. Ponawiam pytanie - kto da mniej

Kolego mokrowski - kod nie zaliczony ;P TOP dla trybu CTC ustawiony na 9, TCNT nigdy nie doliczy do "wait_to". Obserwacje potwierdzone empirycznie - kostka wymaga resetu po użyciu

Kolega anshar i tak zniszczył system ;] Brawo!



Przy czym mam wrażenie, że po wyrzuceniu attrybutów funkcji main (w szczególności "naked") wyniki "rzutu kostką" są bardziej losowe. Wiąże się to z małym wzrostem objętości kodu - 2B. W ogóle w pierwszej chwili zdurniałem jak odpaliłem ten program - "gaszenie" wylosowanej cyfry odbywa się w iście szatański sposób Btw. jak ocenić losowość wyników ?

Dodano:

Ten mikroprogram nie korzysta ze stosu - można wywalić ustawienie wierzchołka - 4B do przodu

Kolega xor zwrócił uwagę na problem zużycia energii. Jeśli dozwolone są zmiany sprzętowe to proponuję przełożyć "baton losujący" na pin reset. Po resecie losowanie i wyświetlenie wartości, potem uśpienie procka na czas ~1,5s. Wybudzenie np. watchdogiem. W przerwaniu od wdt zgaszenie ledów i powerdown mikrokontrolera. Niestety trzeba wtedy opracować inny random generator.

@mokrowski - Twoja kostka jest dosyć "szulerska" Po resecie programu pętla for trwa za krótko żeby dało się "losowo" wstrzelić z przyciskiem. Dalej program czeka w pętli while(1) - 99% wciśnięć przycisku będzie w czasie oczekiwania w while - więc wynik losowania zawsze będzie ten sam. Dodatkowo przez te ~2s stan przycisku nie jest sprawdzany - trzeba go dłużej trzymać. Poza tym działa ok Pisanie "na sucho" (bez możliwości sprawdzenia z hardware'em) zdecydowanie jest złem!
Pozwoliłem sobie troszkę przerobić, żeby usunąć w/w problemy, powstało toto (52B):



Konfiguracja wdt wrzucona w pętlę while żeby czas wyświetlania wylosowanej wartości był stały - nie jest to może "książkowy" sposób kasowania wdt... ale jeśli coś jest głupie i działa to nie jest głupie

A proszę bardzo: kto powiedział, że r1 i SREG muszą być zerowane R1 nigdzie jest jest używany... Co do flag w sreg... cóż... program działa.





--------------------

Pomysł z podłączeniem przycisku do resetu dotyczył głównie postu kolegi xor o oszczędzaniu energii. Ale "power-saving" to raczej osobny challenge.
Też myślałem o ADC, tylko nie byłem przekonany czy się nie naładują jakie pojemności wejściowe ADC i nici z losowości.

Mi się zdaje, że w ogóle losowość dostaje trochę po nosie: wduszenie batona w dowolnym momencie między klamrą zamykającą pętlę a rozpoczęciem pętli zawsze da zero, nieprawdaż?

Co do powerdowna, ja to bym widział tak (chociaż nie wiem czy zadziała to tak jak myślę - jeszcze się czymś takim nie bawiłem ): wciśnięcie batona losującego budzi procek przez przerwanie PCINT albo INT0 (w tym wypadku trzeba przenieść baton na inny pin - PB1 OIDP. W obu przypadkach trzeba by podłączyć zewnętrzny pull-up). Losowanie w momencie puszczenia batona, a więc wynik funkcji losującej zależy od długości trzymania batona (chyba jest to wystarczająco losowe?). Delay odmierza czas wyświetlania (paskudny ale procek i tak nie ma nic innego do roboty), potem skok na początek pętli i ponowne uśpienie. Konieczne zmiany w hardware: oprócz przeniesienia batona i dodania rezystora, trzeba "obrócić" diody (anody-pin, katody do GND)

_________________
+++++[>++++<-]>[>++++++<-]>.---------.+++.

Masz rację, zero ma większe prawdopodobieństwo wylosowania Co do powersavingu: zamiast delaya proponuję ustawienie jakiegoś timera/wdt i uśpienie procka.

Daję słowo, że jeszcze pisałem swój post gdy wytknąłeś to mokrowskiemu


Nie bardzo się da, bo w powerdown piny są utrzymywane w stanie LOW (dlatego właśnie mówiłem o zmianie polaryzacji diod). Przynajmniej tak zrozumiałem z dataszita.

_________________
+++++[>++++<-]>[>++++++<-]>.---------.+++.

@mokrowski, tutaj wizualizacja, twoich założeń

_________________
Migracja z punktu B do punktu C
Pozdrawiam

@xor - no to chociaż Idle można zaaplikować - zawsze coś.
@mokrowski - hm nie powiem ten pomysł z czujnikiem drgań korci. Muszę się z tym "przespać" Przyjemnym ficzerem byłoby "zupełnie przypadkowe wyrzucanie szóstki po wykryciu 'ręki Pana-stworzyciela'"

Swoją drogą - ponowię pytanie o ocenę "losowości" - można jakoś matematycznie ocenić losowość wyników? Wydaje mi się że nie bardzo, ale może się mylę?

Hehe, nie o paranoję tu chodzi Z ciekawości pytam. Bo złapałem się na tym, że "intuicyjnie" czułem, że jeśli elektroniczna-kostka np. 3 razy pod rząd wylosuje taką samą liczbę - to coś jest nie tak. Ale przecież prawdopodobieństwo wyrzucenia konkretnej wartości jest stałe (zakładam, że kostka działa i żadne zera nie są uprzywilejowane) - nie zależne od tego, co wypadło wcześniej. Więc wyniki 1-1-1 są "równie losowe" jak 1-2-3, 3-6-1 itd...

Hm stały rozkład powiadasz. Obawiam się, że nasza kostka miały by jakiś bardziej wykładniczy - zorientowany na zero jak zauważył kolega xor ;d Dlatego tez pozwolę sobie wrzucić jeszcze jeden wsad do kostki (ostatni - obiecuję!) - wydaje mi się, że pozbawiony tej wady.



Jest tu jeszcze jedna mała sztuczka - ustawienie preskalera TIM0 jest tak dobrane, aby do TCCR0B była wpisywana liczba 5. Linijkę wyżej też jest wykorzystywana piątka. Dzięki temu stała "5" jest tylko raz ładowana do rejestru - a kod jest o 2B krótszy Całość zajmuje 50B.

Sekwencja potrząśnięć, może jakieś gwizdnięcie przy rzucaniu, chuchnięcie na szczęście, dotknięcie w odpowiednim miejscu czy inny niewinny gest rodem z filmu Ocean's Thirteen.

Dziękuję za podrzucenie lektury

ACHTUNG! W programie jest mały bug (dotyczy też kilku poprzednich wersji moich i kolegi mokrowskiego), co słusznie zauważył kolega xor - zainteresowanych uprasza się o doczytanie wątku do końca

Tu chyba brakuje pgm_read_byte?

_________________
+++++[>++++<-]>[>++++++<-]>.---------.+++.

Gdyby port_val[] było zdefiniowane z PROGMEM to owszem - konieczne byłoby użycie pgm_read_byte. Na szczęście (?) developerzy avr-gcc zakasali rękawy i wzięli się za te nieszczęsne przestrzenie adresowe. Użycie __flash zamiast PROGMEM załatwia sprawę makr pgm_read_xxx.

Do poczytania: klik

Czyli teraz ze stałymi we FLASH można stosować normalne operatory? To wspaniała wiadomość! Szkoda, że nic o tym nie ma w dokumentacji avr-libc (no dobra, rozumiem, że to jest ficzer gcc nie mający nic wspólnego z gcc). To oczywiście działa w toolchainie atmelowskim?

_________________
+++++[>++++<-]>[>++++++<-]>.---------.+++.

Wyglada na to, ze dziala chociaz pokazuje warninga.

Warninga pokazuje kompilator czy analizator kodu w Eclipse ;> ?

U mnie eclipse warczy, że __flash to syntax error, a stała zadeklarowana w ten sposób "could not be roselved". Bidulek nie wie jak to ugryźć Na szczęście kompilator nie ma oporów (gcc 4.8.2).

Ficzer pojawił się w gcc od wersji 4.7, wcześniej był do tego jakiś patch z tego co się orientuję. Nie wiem na której wersji jest oparty oficjalny atmelowy toolchain. Mam zainstalowanego linuksa i w sumie nie wiem skąd ubunciak pobrał avr-gcc. Póki wszystko działa to mi to zwisa Najłatwiej (i najfajniej) - potestować sobie

No tak masz rację, analizator kodu w Eclipsie!

Działa (gcc 4.7.2)
...chociaż wywala syntax error
...i nie mogę go wyłączyć :-/

Jeszcze mała uwaga do programu na zakończenie: funkcja main bez atrybutów jest w hexie wstawiana za tablicą. To chyba może być problem

_________________
+++++[>++++<-]>[>++++++<-]>.---------.+++.

Wow! Ale kolega wypatrzył bug'a Dopisałem ostrzeżenie przy ostatniej wersji programu.

Faktycznie - musi być __attribute__((section (".vectors") )) żeby main lądował na początku pamięci. Swoją drogą, ciekawe co za rozkazy kryją się "w tablicy", trzeba będzie sprawdzić ;d

Przy okazji - w 84r. kod wykorzystujący analogiczny mechanizm wygrał konkurs IOCCC (link do programu mullender.c)

(dodano po chwili) Jakby kogoś interesowało to tablica port_val zinterpretowano jako kod programu, przedstawia się następująco: