ATNEL tech-forum

Re: Kostka do gry na Attiny13

2015-03-21T07:40:55+01:00

iframe

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

Statystyki: Napisane przez artur85 — 21 mar 2015, o 07:40

Re: Kostka do gry na Attiny13

2015-03-03T19:34:08+01:00

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ę?

Statystyki: Napisane przez Gość — 3 mar 2015, o 19:34

Re: Kostka do gry na Attiny13

2015-03-03T18:32:59+01:00

mokrowski napisał(a):

Prawy myszy na projekcie -> Properties -> C/C++ General -> Preprocessor Include Path -> Languages: GNU C -> CDT User Setting Entries -> Add -> Preprocessor Macro w okienku #-> Name = __flash -> Value = /**/, zaznaczone Treat as built-in.

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!

Statystyki: Napisane przez xor — 3 mar 2015, o 18:32

Re: Kostka do gry na Attiny13

2015-03-03T18:18:49+01:00

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ć

Statystyki: Napisane przez Gość — 3 mar 2015, o 18:18

Re: Kostka do gry na Attiny13

2015-03-03T15:50:52+01:00

mokrowski napisał(a):

Mam nieodparte wrażenie że charlieplexing jest trochę takim ,,tabu" którego wszyscy się boją

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

----

mokrowski napisał(a):

No to będziesz wpadał, bo wiesz gdzie... ale rozwiązanie jest nieeleganckie

i nie działa
dalej jest syntax error ;/

Statystyki: Napisane przez Gość — 3 mar 2015, o 15:34

Re: Kostka do gry na Attiny13

2015-03-03T14:38:27+01:00

@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 ?

Statystyki: Napisane przez Gość — 3 mar 2015, o 14:38

Re: Kostka do gry na Attiny13

2015-03-02T23:02:24+01:00

wwojtek napisał(a):

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 ;/

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:

[syntax=asm]000000c8

:
c8:cf 93 pushr28
ca:df 93 pushr29
cc:00 d0 rcall.+0 ; 0xce
ce:00 d0 rcall.+0 ; 0xd0
d0:00 d0 rcall.+0 ; 0xd2
d2:cd b7 inr28, 0x3d; 61
d4:de b7 inr29, 0x3e; 62
...[/syntax]

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

[syntax=asm]000000c8

:
c8:cd b7 inr28, 0x3d; 61
ca:de b7 inr29, 0x3e; 62
...[/syntax]

wwojtek napisał(a):

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

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.

wwojtek napisał(a):

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

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 ).

wwojtek napisał(a):

4. "MCUSR = 0; //Niewyzerowana flaga WDRF nie pozwoli na wyłączenie resetu" - chyba coś zgubiłem ;/ jakiego resetu?

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ć.

Statystyki: Napisane przez xor — 2 mar 2015, o 23:02

Re: Kostka do gry na Attiny13

2015-03-02T10:00:36+01:00

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?

Statystyki: Napisane przez Gość — 2 mar 2015, o 10:00

Re: Kostka do gry na Attiny13

2015-03-01T19:05:51+01:00

mokrowski napisał(a):

szczególnie przy ARM

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 [syntax=c]#pragma GCC diagnostic ignored "-Wtwój_rodzaj_warninga"[/syntax]
skoro Eclipse nic nie pokazuje oprócz lakonicznego "Syntax error".

Statystyki: Napisane przez xor — 1 mar 2015, o 19:05

Re: Kostka do gry na Attiny13

2015-03-01T16:59:00+01:00

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.

Statystyki: Napisane przez xor — 1 mar 2015, o 16:59

Re: Kostka do gry na Attiny13

2015-02-28T22:45:44+01:00

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.

Statystyki: Napisane przez majster — 28 lut 2015, o 22:45

Re: Kostka do gry na Attiny13

2015-02-22T15:54:55+01:00

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?

[syntax=c]/*
* main_4.c
*
* Created on: 22 lut 2015
* Author: slawek
*/

/*
* Fusebity m168p: low 0x42, high 0xdf, ext 0x01
* BODLEVEL: off
* SUT_CKSEL: Int RC OSC 6/14 + 0ms
* CKDIV8: on
* WDTON: off
*/

//TODO: zrobić porządek z ustawianiem nieużywanch pinów przy wyświetlaniu

#include
#include
#include
#include
#include
#include

#define OUT_PORTPORTD
#define OUT_PINPIND
#define OUT_DDRDDRD

#define BUTTON_MASK(_BV(PD2))
#define DOT(_BV(PD0))//1, 3, 5
#define BACKSLASH(_BV(PD1))//2, 3, 4, 5, 6
#define SLASH(_BV(PD3))//4, 5, 6
#define DASH(_BV(PD4))//6
#define LED_MASK( DOT | BACKSLASH | SLASH | DASH )

#define BLINKS1//ile mrugnięć diody po włączeniu zasilania
#define BLINKS_RST5//ile mrugnięć diody po zbyt długim trzymaniu batona

#define NOT_YET0//wartość zmiennej wskazująca, że losowanie jeszcze trwa

#define ARR_SIZE(ARR) (sizeof(ARR)/sizeof(ARR[0]))

const uint8_t __flash port_val[] = {
((~DOT) & LED_MASK) | BUTTON_MASK,
((~BACKSLASH)& LED_MASK) | BUTTON_MASK,
((~(DOT | BACKSLASH)) & LED_MASK) | BUTTON_MASK,
((~(BACKSLASH | SLASH)) & LED_MASK) | BUTTON_MASK,
((~(DOT | BACKSLASH | SLASH))& LED_MASK) | BUTTON_MASK,
((~(BACKSLASH | SLASH | DASH)) & LED_MASK) | BUTTON_MASK
} ;

//wylosowana liczba
volatile uint8_t rand_value;
//przypisanie wylosowanej liczby przy pierwszej zmianie stanu klawisz
volatile uint8_t rand_flag= NOT_YET;

inline void powersave_init(void);
inline void io_init(void);
inline void timer_init(void);
inline void blink(void);
inline void spin();
void set_wdt_interrupt(uint8_t);

int main(void) __attribute__((OS_main));
int main(void)
{
//wyłączenie nieużywanych podzespołów
powersave_init();
//init używanych wejść
io_init();
//ustawienie timera losującego
timer_init();
//za wyjątkiem czasu losowania µC będzie w stanie Power Down
set_sleep_mode(SLEEP_MODE_PWR_DOWN);

sei();

//pokaż że działasz albo że nastąpił reset
blink();

while(1)
{
//włącz button by można było wybudzić procka
PCMSK2 = _BV(PCINT18);
//śpij aż do wciśnięcia przycisku
sleep_mode();
//Start zegara to 6+14 cykli, wywołanie przerwania to 4 cykle plus 5 cykli
//na wybudzenie (czy można doliczyć?) plus 3 cykle na powrót, razem 27-32 cykle
//Przy F_CPU 1MHz daje to 27-32µs
//Wliczając kolejne instrukcje (oraz ewentualne wywołania przerwań w wyniku drgania
//styków-wyłączyć?) powinno to załatwić problem bouncignu (drgania muszą być wygaszone
//przed następnym uśpieniem. W razie czego przed kolejnym sleep_mode można dodać
//kilka nopów czy rjmp +0 (albo w ISR ;-))
asm volatile("rjmp .+0");asm volatile("rjmp .+0");
asm volatile("rjmp .+0");asm volatile("rjmp .+0");
asm volatile("rjmp .+0");asm volatile("rjmp .+0");
asm volatile("rjmp .+0");asm volatile("rjmp .+0");
asm volatile("rjmp .+0");asm volatile("rjmp .+0");

//rozpocznij losowanie aż do puszczenia przycisku
TCNT0 = 0;
set_sleep_mode(SLEEP_MODE_IDLE);
rand_flag = NOT_YET;
//do tego momentu drgania stykow powinny wygasnąć, a więc jeżeli na pinie przycisku
//jest stan wysoki to znaczy, że guzik jest niewciśnięty co jest nieprawidłowe
//zapodajemy reset dla uzdrowienia sytuacji
if( OUT_PIN & BUTTON_MASK )
{
wdt_enable(WDTO_15MS);
while(1);
}
//guzik jest wduszony - pokaż kręciołka, że losujesz
spin();
// sleep_mode();
//mamy wylosowaną liczbę
//wyświetl liczbę
OUT_PORT = port_val[rand_value];
//button chwilowo wyłączamy aby zapwenić niezakłócone wyświetlanie
PCMSK2 &= ~_BV(PCINT18);
//przerwanie watchdoga zakończy wyświetlanie
set_wdt_interrupt(WDTO_2S);
set_sleep_mode(SLEEP_MODE_PWR_DOWN);
sleep_mode();
//koniec wyświetlania, przygotuj się do snu
//wyłącz Watchdoga
wdt_disable();
//wyłącz diody
OUT_PORT |= LED_MASK;
}

}

inline void powersave_init(void)
{
//*************** OSZCZĘDZANIE ENERGII **********************
//BOD, Watchdog wyłączone fusbitami. ADC jest domyślnie wyłączony
//Wyłączamy pozostałe podzespoły...
power_all_disable();
//...jednak Timer0 będzie nam potrzebny
power_timer0_enable();

//Wyłączenie komparatora analogowego. Aref też się wyłącza.
ACSR |= _BV(ACD);

//wyłączenie wejść cyfrowych ADC
DIDR0 = _BV(ADC0D) | _BV(ADC1D) | _BV(ADC2D) | _BV(ADC3D) | _BV(ADC4D) | _BV(ADC5D);

//spowolnienie zegara (do 1MHz)
//clock_prescale_set(clock_div_8); //ustawione przez CKDIV8

//ustawianie nieużywanych portów jako wejścia z pullupem
//todo: w czasie pracy włączać pullup
//przed wejśćiem w powerdown wyłączać pullup
//PORTB = 0xff;
//PORTD |= _BV(PD5) | _BV(PD6) | _BV(PD7);
}

inline void io_init(void)
{
//Wyjścia
//PD0 - środkowa kropka, PD1 - przekątna lewo/góra-prawo/dół,
//PD3 - przekątna lewo/dół-prawo/góra, PD4 - poziomo
//Wejścia
//PD2 (PCINT18)- button
OUT_DDR = LED_MASK; // ustawienie wyjść
OUT_PORT |= LED_MASK;// wyłączenie diod (wysterowane stanem niskim)
OUT_PORT |= BUTTON_MASK; //pullup na button

//Ustawienie Pin Change Interrupt na przycisku
PCICR = _BV(PCIE2);
// PCMSK2 = _BV(PCINT18);
}

inline void timer_init(void)
{
TCCR0A = _BV(WGM01);//tryb CTC
TCCR0B = _BV(CS00);//szybkość "mieszania" liczb (preskaler 1, może raczej 8 lub nawet 64??)
OCR0A = 5;
}

inline void blink(void)
{
uint8_t i = MCUSR & _BV(WDRF) ? BLINKS_RST : BLINKS; //dla inicjacji od resetu WD więcej mignięc

MCUSR = 0;//Niewyzerowana flaga WDRF nie pozwoli na wyłączenie resetu
set_wdt_interrupt(WDTO_500MS);
sleep_mode();
set_wdt_interrupt(WDTO_60MS);
for(i+=i; i; i--)
{
OUT_PORT ^= LED_MASK;
sleep_mode();
}
wdt_disable();
//OUT_PORT = LED_MASK;
}

inline void spin()
{
static const uint8_t __flash spin_val[] = {
((~(DOT | DASH)) & LED_MASK) | BUTTON_MASK,
((~(DASH)) & LED_MASK) | BUTTON_MASK,
((~(DOT | SLASH)) & LED_MASK) | BUTTON_MASK,
((~(SLASH)) & LED_MASK) | BUTTON_MASK,
((~(DOT | BACKSLASH)) & LED_MASK) | BUTTON_MASK,
((~(BACKSLASH)) & LED_MASK) | BUTTON_MASK
};
uint8_t i;

//poczekaj z wyświetlaniem kręcioła żeby uniknąć migania przy szybkim zwolnieniu przycisku
set_wdt_interrupt(WDTO_60MS);
sleep_mode();
set_wdt_interrupt(WDTO_30MS);
//wyświetlaj kręcioła aż do otrzymania wartośći rand (czyli puszczenia przycisku)
while(rand_flag == NOT_YET)
{
if(i>=ARR_SIZE(spin_val))
i=0;
OUT_PORT = spin_val[i++];
sleep_mode();
}
OUT_PORT = LED_MASK;
wdt_disable();
}

void set_wdt_interrupt(uint8_t timeout)
{
uint8_t tmp = _BV(WDIE) | (timeout & 0x07) | (timeout&0x08 ? _BV(WDP3) : 0);

ATOMIC_BLOCK(ATOMIC_FORCEON)
{
wdt_reset();
WDTCSR = (1 << WDCE) | (1 << WDE);
WDTCSR = tmp;
}
}

//EMPTY_INTERRUPT(PCINT2_vect)
ISR(PCINT2_vect)
{
uint8_t tmp = rand_flag;

if(tmp == NOT_YET)
{
rand_value = TCNT0;
rand_flag = !NOT_YET;
}
}

EMPTY_INTERRUPT(WDT_vect)
//ISR(WDT_vect)
//{
//OUTPORT ^= DOT;
//}[/syntax]

Działa to tak:

iframe

Statystyki: Napisane przez xor — 22 lut 2015, o 15:54

Re: Kostka do gry na Attiny13

2015-02-18T20:16:23+01:00

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ł.

[syntax=c]/*
* main_3.c
*
* Created on: 14 lut 2015
* Author: slawek
*/

/*
* Fusebity m168p: low 0x42, high 0xdf, ext 0x01
* BODLEVEL: off
* SUT_CKSEL: Int RC OSC 6/14 + 0ms
* CKDIV8: on
* WDTON: off
*/

//TODO: zrobić porządek z ustawianiem nieużywanch pinów przy wyświetlaniu

#include
#include
#include
#include
#include
#include

#define OUT_PORTPORTD
#define OUT_DDRDDRD
#define BUTTON_MASK(_BV(PD2))
#define DOT(_BV(PD0))//1, 3, 5
#define BACKSLASH(_BV(PD1))//2, 3, 4, 5, 6
#define SLASH(_BV(PD3))//4, 5, 6
#define DASH(_BV(PD4))//6
#define LED_MASK( DOT | BACKSLASH | SLASH | DASH )
#define BLINKS1//ile mrugnięć diody po włączeniu zasilania
#define BLINKS_RST5//ile mrugnięć diody po zbyt długim trzymaniu batona

const uint8_t __flash port_val[] = {
((~DOT) & LED_MASK) | BUTTON_MASK,
((~BACKSLASH)& LED_MASK) | BUTTON_MASK,
((~(DOT | BACKSLASH)) & LED_MASK) | BUTTON_MASK,
((~(BACKSLASH | SLASH)) & LED_MASK) | BUTTON_MASK,
((~(DOT | BACKSLASH | SLASH))& LED_MASK) | BUTTON_MASK,
((~(BACKSLASH | SLASH | DASH)) & LED_MASK) | BUTTON_MASK
} ;

void inline powersave_init(void);
void inline io_init(void);
void inline timer_init(void);
void inline blink(void);
void set_wdt_interrupt(uint8_t);

int main(void) __attribute__((OS_main));
int main(void)
{
//wyłączenie nieużywanych podzespołów
powersave_init();
//init używanych wejść
io_init();
//ustawienie timera losującego
timer_init();
//za wyjątkiem czasu losowania µC będzie w stanie Power Down
set_sleep_mode(SLEEP_MODE_PWR_DOWN);

sei();

//pokaż że działasz albo że nastąpił reset
blink();

while(1)
{
//włącz button by można było wybudzić procka
PCMSK2 = _BV(PCINT18);
//śpij aż do wciśnięcia przycisku
sleep_mode();
//Start zegara to 6+14 cykli, wywołanie przerwania to 4 cykle plus 5 cykli
//na wybudzenie (czy można doliczyć?) plus 3 cykle na powrót, razem 27-32 cykle
//Przy F_CPU 1MHz daje to 27-32µs
//Wliczając kolejne instrukcje (oraz ewentualne wywołania przerwań w wyniku drgania
//styków-wyłączyć?) powinno to załatwić problem bouncignu (drgania muszą być wygaszone
//przed następnym uśpieniem. W razie czego przed kolejnym sleep_mode można dodać
//kilka nopów czy rjmp +0 (albo w ISR ;-))

//rozpocznij losowanie aż do puszczenia przycisku
TCNT0 = 0;
set_sleep_mode(SLEEP_MODE_IDLE);
//ogranicz czas losowania na maksimum 4s, potem resetuj µC
//jednocześnie jest to zabezpieczenie przed sytuacją gdy wejście w power down
//nastąpiło z wciśniętym przyciskiem
wdt_enable(WDTO_4S);
sleep_mode();
//mamy wylosowaną liczbę
wdt_reset();
//wyświetl liczbę
OUT_PORT = port_val[TCNT0];
//button chwilowo wyłączamy aby zapwenić niezakłócone wyświetlanie
PCMSK2 &= ~_BV(PCINT18);
//przerwanie watchdoga zakończy wyświetlanie
set_wdt_interrupt(WDTO_2S);
set_sleep_mode(SLEEP_MODE_PWR_DOWN);
sleep_mode();
//koniec wyświetlania, przygotuj się do snu
//wyłącz Watchdoga
wdt_disable();
//wyłącz diody
OUT_PORT |= LED_MASK;
}

}

inline void powersave_init(void)
{
//*************** OSZCZĘDZANIE ENERGII **********************
//BOD, Watchdog wyłączone fusbitami. ADC jest domyślnie wyłączony
//Wyłączamy pozostałe podzespoły...
power_all_disable();
//...jednak Timer0 będzie nam potrzebny
power_timer0_enable();

//Wyłączenie komparatora analogowego. Aref też się wyłącza.
ACSR |= _BV(ACD);

//wyłączenie wejść cyfrowych ADC
DIDR0 = _BV(ADC0D) | _BV(ADC1D) | _BV(ADC2D) | _BV(ADC3D) | _BV(ADC4D) | _BV(ADC5D);

//spowolnienie zegara (do 1MHz)
//clock_prescale_set(clock_div_8); //ustawione przez CKDIV8

//ustawianie nieużywanych portów jako wejścia z pullupem
//todo: w czasie pracy włączać pullup
//przed wejśćiem w powerdown wyłączać pullup
//PORTB = 0xff;
//PORTD |= _BV(PD5) | _BV(PD6) | _BV(PD7);
}

inline void io_init(void)
{
//Wyjścia
//PD0 - środkowa kropka, PD1 - przekątna lewo/góra-prawo/dół,
//PD3 - przekątna lewo/dół-prawo/góra, PD4 - poziomo
//Wejścia
//PD2 (PCINT18)- button
OUT_DDR = LED_MASK; // ustawienie wyjść
OUT_PORT |= LED_MASK;// wyłączenie diod (wysterowane stanem niskim)
OUT_PORT |= BUTTON_MASK; //pullup na button

//Ustawienie Pin Change Interrupt na przycisku
PCICR = _BV(PCIE2);
// PCMSK2 = _BV(PCINT18);
}

inline void timer_init(void)
{
TCCR0A = _BV(WGM01);//tryb CTC
TCCR0B = _BV(CS00);//szybkość "mieszania" liczb (preskaler 1, może raczej 8 lub nawet 64??)
OCR0A = 5;
}

inline void blink(void)
{
uint8_t i = MCUSR & _BV(WDRF) ? BLINKS_RST : BLINKS; //dla inicjacji od resetu WD więcej mignięc

MCUSR = 0;//Niewyzerowana flaga WDRF nie pozwoli na wyłączenie resetu
set_wdt_interrupt(WDTO_500MS);
sleep_mode();
set_wdt_interrupt(WDTO_60MS);
for(i+=i; i; i--)
{
OUT_PORT ^= LED_MASK;
sleep_mode();
}
wdt_disable();
//OUT_PORT = LED_MASK;
}

void set_wdt_interrupt(uint8_t timeout)
{
uint8_t tmp = _BV(WDIE) | (timeout & 0x07) | (timeout&0x08 ? _BV(WDP3) : 0);

ATOMIC_BLOCK(ATOMIC_FORCEON)
{
wdt_reset();
WDTCSR = (1 << WDCE) | (1 << WDE);
WDTCSR = tmp;
}
}

EMPTY_INTERRUPT(PCINT2_vect)

EMPTY_INTERRUPT(WDT_vect)
//ISR(WDT_vect)
//{
//OUTPORT ^= DOT;
//}[/syntax]

Statystyki: Napisane przez xor — 18 lut 2015, o 20:16

Re: Kostka do gry na Attiny13

2015-02-09T11:55:22+01:00

mokrowski napisał(a):

Ale ja już nie będę celował w ilość bajtów kodu tylko w ,,fiuczery" kostki

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

Statystyki: Napisane przez WoodPaker — 9 lut 2015, o 11:55

Re: Kostka do gry na Attiny13

2015-02-09T11:16:34+01:00

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

iframe

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

Statystyki: Napisane przez artur85 — 9 lut 2015, o 11:16

Re: Kostka do gry na Attiny13

2015-02-08T23:36:42+01:00

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

Statystyki: Napisane przez anshar — 8 lut 2015, o 23:36

Re: Kostka do gry na Attiny13

2015-02-09T08:00:22+01:00

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

[syntax=c]/*
* main_2.c
*
* Created on: 8 lut 2015
* Author: slawek
*/

/*
* Fusebity m168p: low 0x42, high 0xdf, ext 0x01
* BODLEVEL: off
* SUT_CKSEL: Int RC OSC 6/14 + 0ms
* CKDIV8: on
* WDTON: off
*/

#include
#include
#include
#include
#include
#include

enum wdt_sets {WDT_25 = _BV(WDP2),
WDT_2S = _BV(WDP0)|_BV(WDP1)|_BV(WDP2),
WDT_4S = _BV(WDP3)
};

const uint8_t __flash port_val[] = {
((~_BV(PD0)) & (_BV(PD0) | _BV(PD1) | _BV(PD3) |_BV(PD4))) | _BV(PD2),
((~_BV(PD1)) & (_BV(PD0) | _BV(PD1) | _BV(PD3) |_BV(PD4))) | _BV(PD2),
((~(_BV(PD0) | _BV(PD1))) & (_BV(PD0) | _BV(PD1) | _BV(PD3) |_BV(PD4))) | _BV(PD2),
((~(_BV(PD1) | _BV(PD3))) & (_BV(PD0) | _BV(PD1) | _BV(PD3) |_BV(PD4))) | _BV(PD2),
((~(_BV(PD0) | _BV(PD1) |_BV(PD3))) & (_BV(PD0) | _BV(PD1) | _BV(PD3) |_BV(PD4))) | _BV(PD2),
((~(_BV(PD1) | _BV(PD3) |_BV(PD4))) & (_BV(PD0) | _BV(PD1) | _BV(PD3) |_BV(PD4))) | _BV(PD2)
} ;

void powersave_init(void);
void io_init(void);
void timer_init(void);
void set_wdt(enum wdt_sets);

int main(void) __attribute__((OS_main));
int main(void)
{
powersave_init();
io_init();
timer_init();

//Ustaw początkowy tryb oszczędzania energii
set_sleep_mode(SLEEP_MODE_PWR_DOWN);

sei();
while(1)
{
//śpij aż do wciśnięcia przycisku
//todo: zapewnić, że µC nie zaśnie z wciśniętym przyciskiem
sleep_mode();
//Start zegara to 6+14 cykli, wywołanie przerwania to 4 cykle plus 5 cykli
//na wybudzenie (czy można doliczyć?) plus 3 cykle na powrót, razem 27-32 cykle
//Przy F_CPU 1MHz daje to 27-32µs
//Wliczając kolejne (oraz ewentualne wywołania przerwań w wyniku drgania
//styków-wyłączyć?) powinno to załatwić problem bouncignu (drgania muszą być wygaszone
//przed następnym uśpieniem

//zresetuj timer oraz wprowadź µC w tryb idle
TCNT0 = 0;
set_sleep_mode(SLEEP_MODE_IDLE);
//śpij aż do puszczenia przycisku
sleep_mode();
//mamy wylosowaną liczbę
//wyświetl liczbę
PORTD = port_val[TCNT0];
//wyłącz button żeby przypadkiem nie wyłączyć wyświetlania
PCMSK2 &= ~_BV(PCINT18);
//włącz watchdog interrupt 2 s
set_wdt(WDT_2S);
set_sleep_mode(SLEEP_MODE_PWR_DOWN);
//Wyświetla aż do wybudzenia przez Watchdog
sleep_mode();
//wyłącz diody
PORTD |= _BV(PD0) | _BV(PD1) | _BV(PD3) | _BV(PD4);
//wyłącz Watchdoga
wdt_disable();
//włącz button by można było wybudzić procka
PCMSK2 = _BV(PCINT18);
}

}

inline void powersave_init(void)
{
//*************** OSZCZĘDZANIE ENERGII **********************
//BOD, Watchdog wyłączone fusbitami. ADC jest domyślnie wyłączony
//Wyłączamy pozostałe podzespoły...
power_all_disable();
//...jednak Timer0 będzie nam potrzebny
power_timer0_enable();

//Wyłączenie komparatora analogowego. Aref też się wyłącza.
ACSR |= _BV(ACD);

//wyłączenie wejść cyfrowych ADC
DIDR0 = _BV(ADC0D) | _BV(ADC1D) | _BV(ADC2D) | _BV(ADC3D) | _BV(ADC4D) | _BV(ADC5D);

//spowolnienie zegara (do 1MHz)
//clock_prescale_set(clock_div_8); //ustawione przez CKDIV8

//ustawianie nieużywanych portów jako wejścia z pullupem
//PORTB = 0xff;
//PORTD |= _BV(PD5) | _BV(PD6) | _BV(PD7);
}

inline void io_init(void)
{
//Wyjścia
//PD0 - środkowa kropka, PD1 - przekątna lewo/góra-prawo/dół,
//PD3 - przekątna lewo/dół-prawo/góra, PD4 - poziomo
//Wejścia
//PD2 (PCINT18)- button
DDRD = _BV(PD0) | _BV(PD1) | _BV(PD3) | _BV(PD4); // ustawienie wyjść
PORTD |= _BV(PD0) | _BV(PD1) | _BV(PD3) | _BV(PD4);// wyłączenie diod (wysterowane stanem niskim)
PORTD |= _BV(PD2); //pullup na button

//Ustawienie Pin Change Interrupt na przycisku
PCICR = _BV(PCIE2);
PCMSK2 = _BV(PCINT18);
}

inline void timer_init(void)
{
TCCR0A = _BV(WGM01);//tryb CTC
TCCR0B = _BV(CS00);//preskaler 1 (może raczej 8 lub nawet 64??)
OCR0A = 5;
}

void set_wdt(enum wdt_sets prescaler)
{
uint8_t tmp = _BV(WDIE) | prescaler;

ATOMIC_BLOCK(ATOMIC_FORCEON)
{
wdt_reset();
WDTCSR = (1 << WDCE) | (1 << WDE);
WDTCSR = tmp;
}
}

EMPTY_INTERRUPT(PCINT2_vect)

EMPTY_INTERRUPT(WDT_vect)[/syntax]

Statystyki: Napisane przez xor — 8 lut 2015, o 20:28

Re: Kostka do gry na Attiny13

2015-01-28T19:58:15+01:00

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ę.

Statystyki: Napisane przez Gość — 28 sty 2015, o 19:58

Re: Kostka do gry na Attiny13

2015-01-28T17:53:28+01:00

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:
[syntax=asm]cp r17, r17
sub r17, r8
adc r1, r26[/syntax]

Statystyki: Napisane przez Gość — 28 sty 2015, o 17:53

Re: Kostka do gry na Attiny13

2015-01-28T15:57:13+01:00

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

Statystyki: Napisane przez xor — 28 sty 2015, o 15:57

Re: Kostka do gry na Attiny13

2015-01-28T14:22:15+01:00

No tak masz rację, analizator kodu w Eclipsie!

Statystyki: Napisane przez anshar — 28 sty 2015, o 14:22

Re: Kostka do gry na Attiny13

2015-01-28T14:04:08+01:00

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

Statystyki: Napisane przez Gość — 28 sty 2015, o 14:04

Re: Kostka do gry na Attiny13

2015-01-28T11:44:25+01:00

Wyglada na to, ze dziala chociaz pokazuje warninga.

Statystyki: Napisane przez anshar — 28 sty 2015, o 11:44

Re: Kostka do gry na Attiny13

2015-01-28T11:29:13+01:00

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?

Statystyki: Napisane przez xor — 28 sty 2015, o 11:29

Re: Kostka do gry na Attiny13

2015-01-28T11:01:11+01:00

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

Statystyki: Napisane przez Gość — 28 sty 2015, o 11:01