Nie kuś w interpreter dla b-f mogę się bawić... tylko kto napisze "programy" testowe w tym paskudztwie?

Przy okazji, cytując kolegę mokrowskiego "to było bardzo pouczające". Nie przypuszczałem, że kostka-challenge zajdzie tak daleko. Wydawało mi się, że 100B to będzie max... znaczy min Również dziękuję.

Pobawiłem się trochę trybami oszczędzania energii i zmodziłem kostkę oszczędną energetycznie. Nie mam dobrego miernika więc pomiary są raczej orientacyjne ale wyszło, że w stanie bezczynności układ pobiera ok 0,1µA (co się zgadza z dataszitem), w czasie losowania prąd waha się między 3 a 1,5mA, podczas wyświetlania wyniku 6,5µA+prąd diod. A więc spokojnie można się pozbyć włącznika; nawet na bateryjce pastylkowej, która ma pojemność ok 100mAh, układ mógłby sobie leżeć gotowy do pracy przez 100 tys. godzin.
Program testowany na atmega168p, ale powinien się dać łatwo przenieść na attiny13 bo nie korzystałem z żadnych ficzerów, które ma atmega a nie ma attiny. Zajętość flasha na m168: 368 bajtów. Schemat niemal identyczny z oryginalnym, jedynie zamiast portu B jest użyty port D i baton został przesunięty z 4 pinu na drugi (PD2) a diodki przesunięte na 3 i 4 pin. To dlatego, że początkowo wybudzanie było przerwaniem INT0. Ostatecznie okazało się, że nie było to potrzebne ale układ już został Program nie jest całkowicie idiotoodporny, jak się wydaje w pewnych warunkach może nie wejść w stan Power Down, a to oznacza znacznie większe zużycie energii (Edit: Już po napisaniu postu przyszedł mi do głowy sposób jak pozbyć się tej wady bez większej przebudowy programu, ale o tym może kiedy indziej). "Produkcyjnie" bym go nie zastosował. Ale pobawić się można

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

Aż nie mogę się doczekać! Ja jeszcze za "cienki" jestem, ale bardzo chętnie to zobaczę! No i do tego, ile znowu się nauczę!

No to może i ja się pochwalę swoim pomysłem. Na początek małe demko

Zamiast diod postanowiłem wykorzystać wyświetlacz 7-segmentowy (z małą pomocą rejestru przesuwnego 74hc595 ). Na razie losowanie liczby odbywa się po zwarciu jednego z pinów do masy, docelowo chcę użyć przerwania INT0, który wybudzi procek i przeprowadzi losowanie. Również chciałbym uruchamiać kostkę poprzez jej potrząśnięcie. Jest też zwalnianie losowania i płynne wygaszanie wyświetlacza. Kodem się pochwalę jak już będzie poprawiony i gotowy, na razie wstyd się z nim pokazywać.
Teraz czekam tylko na paczkę z elementami i zabieram się do projektowania płytki

_________________
zapraszam na bloga http://bakcyl8bit.blogspot.com/

No to jak idziemy w "fiuczery" kostki to proponuję ją urealnić i jeśli mamy projekt jak powyżej to np. dodać zabezpieczenie, że w czasie losowania nie może być po szóstce jedynki albo po trójce czwórki bo jak wiadomo naprzeciwległe pola dają w sumie siedem. Nie ma więc możliwości żeby kostka przekręciła się z 6 na 1 z pominięciem innej liczby

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

I znów odkopię temat Nie bardzo mogłem wymyślić eleganckiego sposobu zapobiegania zawieszeniom kostki w trybie idle (see http://forum.atnel.pl/topic10366-30.html#p117887) więc zastosowałem rozwiązanie typu "weź większy młotek". Ten młotek to wymuszony reset realizowany przez watchdoga. Jeszcze nie wszystko działa tak jakbym chciał, ale w działającym układzie już bym to zastosował.

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

Znów odgrzewam temat, niedługo obejmę funkcję archeologa forum
Przerobiłem ostatni kod dodając trochę animacji na diodkach. Może sobie zmajstruję taką kostkę,a dzieciakom na pewno bardziej się będzie podobać taka bardziej migająca. Przy okazji zmieniłem sposób wykrywania nieprawidłowych wciśnięć. Kod jest na m168p, ale z założeniem, że ma się dać dostosować na attiny, więc nie może używać ficzerów i zasobów, których nie ma na attiny. Stąd intensywne wykorzystanie WDT jako timera. Kod zajmuje 646+2B.
Przy okazji: ktoś wie jak w eclipsie wyłączyć sygnalizowanie errora dla stałych typu __flash?



Działa to tak:

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

ja zrobię wycieczkę wee ołówkiem i na stykówce

a tak na poważnie to też zaczynam się zastanawiać nad taką kostką
gram często z córką w gry planszowe i było by to miłym urozmaiceniem gry

------------------------ [ Dodano po: kilkunastu sekundach ]

ps film masz zablokowany i nie pokazuje się na innych stronach.

_________________
Usługi druku przestrzennego - www.drumik.pl

A ja wpadłem na pomysł jak do układu wg pierwotnego schematu i "mojego" programu wcisnąć buzzer. Prawie się udało: generalnie działa ale pojawiają się zacięcia. Może uda się to zwalczyć.
Co do problemów z __flash: #pragma chyba nie zadziała (przyznam, że nie próbowałem ) bo to nie gcc wywala błąd tylko Eclipse. Próbowałem wyłączać jakieś przełączniki analizy składniowej w ustawieniach Eclipsa ale nic to nie dało.

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

Chyba mówimy o czymś innym. Wg tego: https://gcc.gnu.org/onlinedocs/gcc/Named-Address-Spaces.html kwalifikator __flash działa tylko na AVR.
...chodzi o M32C (to jest ARM?) i kwalifikator __far? No dobra, i tak nie wiem co mam wstawić w
skoro Eclipse nic nie pokazuje oprócz lakonicznego "Syntax error".

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

Wow była kostka ascetyczna, a teraz zaczyna obrastać w wyszukane ficzery - projekt wchodzi w fazę barokową

@mokrowski - syntax error wyrzuca statyczny analizator kodu w eclipse (czy jak to się tam nazywa), nie kompilator - więc pragma niestety nie pomoże ;/ Jak dotąd nie udało mi się znaleźć sposobu żeby się pozbyć tego podkreślania... ale szczerze powiedziawszy specjalnie mi to nie przeszkadza



@xor - nie przyszłoby mi do głowy, że da się tak... elastycznie wykorzystać watchdog'a Ale mam kilka ogólnych pytań, które nasunęły się po analizie Twojego kodu:
1. Zauważyłeś jakąś różnicę po dodaniu atrybutu "OS_main" do main? W kilku projektach sprawdzałem co daje OS_main (ewentualnie noreturn) dodane do main i nigdy nie było różnicy w generowanym kodzie ;/
2. rjmp .+0 vs nop - jest jakaś praktyczna różnica?
I jak to się ma np. w ARM? Z tego co pamiętam to, w Cortex'ach nop może zaginąć gdzieś w pipeline'ie i nie można na nim polegać w 100% jeśli chodzi o opóźnienia. Jakoś nigdy nie pomyślałem, aby zamienić nop'a na coś inszego acz równie nie-produktywnego
3. W ramach optymalizacji można by chyba zrezygnować z rand_flag i przy starcie programu wpisywać do rand_value niemożliwą wartość (>5) co byłoby wyznacznikiem że jeszcze nie było losowania
4. "MCUSR = 0; //Niewyzerowana flaga WDRF nie pozwoli na wyłączenie resetu" - chyba coś zgubiłem ;/ jakiego resetu?

Owszem jest różnica. Z tym atrybutem w prologu main nie są zapisywane rejestry "call-saved", czyli r2-r17, r28, r29. Pewnie jak w main wstawisz same wywołania funkcji i program nie ruszy tych rejestrów to nie zauważysz różnicy (kompilator ich nie zachowa, bo po co).
Mam tu jakiś programik pod ręką - różnica w progmem po skompilowaniu: 4 bajty (bez atrybutu jest więcej). Co gorsze na zachowanie tych rejestrów niepotrzebnie zużywany jest RAM. Początek funkcji main bez OS_main:



Nie wiem po co instrukcje rcall .+0, które nic nie robią choć zużywają 6 bajtów RAMu.
Z OS_main:





Zarówno rjmp jak i nop zajmują we flash jedno słowo, jednak rjmp trwa 2 takty, a nop jeden. A więc mamy 200% normy z jednej instrukcji Z innych ciekawych instrukcji opóźniających, które niedawno stosowałem: para rcall/ret. Trochę kłopotliwa na co dzień, ale w stawce asemblerowej można wykorzystać. Dwa słowa i 7 (lub 9 w prockach z większą pamięcią) taktów - 350% normy. A zważywszy, że w podprogramach instrukcję ret już i tak mamy to i 700% normy
Czy można polegać? Jeśli tylko kompilator instrukcji nie usunie (a po to dajemy volatile, żeby nie usunął) to na 100% można. To nie ARM. Nie, żebym sie jakoś szczególnie znał na ARMach (czy choćby tylko odrobinę ), ale słyszałem że AVR są "real time" a ARM nie.




Można. Po to nawet utworzyłem stałą NOT_YET ale nie lubię takich zlepków, więc dodałem flagę (stała pozostała, choć trochę nie wiadomo po co ).



Trybu reset watchdoga. Jeżeli nastąpił reset zainicjowany przez watchdoga, to procek wstaje z ustawioną flagą WDRF i aktywnym watchdogiem. Trzeba go wyłączyć, żeby nie bruździł. Ale wykonanie sekwencji wyłączającej (ustaw WDCE i WDE i w ciągu 4 taktów wyzeruj WDTCSR) z wciąż ustawioną flagą WDRF, nie odniesie skutku. Uprzednio trzeba go wyzerować.

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

@xor - faktycznie, jak "dorzuciłem" trochę matematyki do main, żeby kompilator pomaglował rejestrami, to jest różnica. Szkoda, że taka subtelna

"rcall .+0" - może coś w tym guście: avrfreaks?

O! Tego o watchdog'u nie wiedziałem

@mokrowski - ... w różnych miejscach w Eclipse szukałem jak dodać __flash'e i __memx'y do "extensions/builtins/keywords" albo czegoś podobnego, ale na to żeby szukać w "Preprocessor Include Path" bym nie wpadł

Co do Twojego kodu... muszę się przyznać - trochę się zaciąłem na wyświetlaniu Pogubiłem się co jest co w led.c - muszę usiąść na spokojnie.
Ale dwie wątpliwości zdążyły się urodzić:
1. Warunek z " 7 == ... " w funkcji get_dice_random_value() -> to jest to o czym pisał WoodPaker (że kostka nie przeskoczy na przeciwległy bok)?
2. Po co wyłączać TIM0?

W ogóle buszując w tym kodzie, napotykając gęsto i często:
"funkcje prywatne"
"static, static, static..."
"get_...()"
"set_...()"
nasunęło mi się jedno pytanie: czemu nie *.cpp ?

Z punktu widzenia głównie-czytającego-hobbysty stwierdzam, że przypadki, w których spotkałem się z charlieplexing'iem mogę policzyć na palcach jednej ręki (mam na myśli wszelkie publikowane projekty, artykuły, poradniki, porady na forum).

Po co są static'i to ja wiem. Tylko, nie wiem czy słusznie, ale w tych działaniach (funkcje i zmienne statyczne, gettery i settery) widzę taką... protezę enkapsulacji*. Aż korci aby to zaklamrować w klasę

* - nie wiem czy to aktualnie poprawna nazwa, zostało mi z dawnych wieczorów spędzonych z Gręboszem

----

i nie działa
dalej jest syntax error ;/

Heh, a jakiś patent na przeciążanie funkcji w wersji "bieda-c" też jest ;d?

Co do errora:
Lubuntu 14.04; Eclipse Luna; plugin AVR, openocd, embsysregview i jakiś wtyczek "wrapujący" długie linijki. Clean'y i Rebuild'y przerabiałem - nic nie pomaga. Swoją drogą ten "syntax error" jest jakiś dziwny - nie powinno być informacji w zakładce "Problems"? Jak w dymku od błędu kliknę w opcję ustawień adnotacji to przenosi mnie do ustawień "C/C++ Indexer Markers"... Żeby było śmieszniej po przeniesieniu "const" na początek linijki, głupieje totalnie i nazwa zmiennej "could not be resolved" w main.
Pogrzebałem trochę w goolach i "wszystkim" działa przedstawiony sposób... czyli tym razem to ja musiałem coś skopać

U mnie działa. GNU/Linux, Eclipse Kepler/AVR plugin 2.4.1/avr-gcc 4.7.2 (atmel toolchain 3.4.2.939)
Jesteś wielki!

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

Znalazłem
Oczywiście pierdoła. Rozwiązania dwa. Generalnie cały szkopuł polegał na tym, że projekt (z tego co rozumiem) korzystał nie z tych ustawień indeksera co bym sobie życzył...

1: Window -> Preference -> C/C++ -> Indexer -> "Build configuration for the indexer" zmienić z "Use the build configuration specified in the project's indexer settings" na "Use active build configuration"

2: Opcje projektu -> C/C++ General -> Indexer -> jako "Build configuration for the indexer" wybrać "Release" (u mnie było Debug)

Jednego nie rozumiem: dlaczego zmiana z Debug na Release (opcja 2) cokolwiek zmienia, skoro w tym samym okienku "Enable project specific settings" nie jest zaptaszone? Jeśli nie zezwalam na odrębne ustawienia dla projektu to zmiana ustawień projektu nie powinna chyba być brana pod uwagę?

No, w końcu udało mi się zebrać elementy i znaleźć trochę czasu na złożenie kostki do kupy. Wielkie dzięki dla kolegi Mokrowskiego za bardzo przyjazny kodzik, z którego udało mi się wybebeszyć biblioteki do obsługi membrany piezo i usypiania procka. Kodem i płytką chyba nie ma się co chwalić, zresztą za jakiś czas powinny się pojawić na moim blogu

_________________
zapraszam na bloga http://bakcyl8bit.blogspot.com/