ATNEL tech-forum

Re: Łączenie warunków

2015-02-22T22:04:20+01:00

rekon napisał(a):

bo dopóki nie zrozumiem dlaczego nie wolno dotykać piekarnika to będę szedł w stronę ciepła

Nie zrozum mnie - źle ... ja to doskonale rozumiem. Wspomniałem o pewnych ogólnych zasadach ... a to nie oznacza, że KAŻDY musi działać tak samo .... a już całkowicie zrozumiałe dla mnie jest gdy ktoś musi przede wszystkim coś zrozumieć "po swojemu" .... toż to normalne .... i absolutnie nie chodzi przecież o to aby tu ktoś komuś narzucał jakieś zdanie ... przede wszystkim programowanie - to fajna zabawa a tym bardziej jeśli można się dzielić tyloma ciekawymi opiniami, poradami ... i podyskutować na spokojnie.

Statystyki: Napisane przez mirekk36 — 22 lut 2015, o 22:04

Re: Łączenie warunków

2015-02-22T21:24:44+01:00

mirekk36 wg. mnie chodzi o wyższość, bo dopóki nie zrozumiem dlaczego nie wolno dotykać piekarnika to będę szedł w stronę ciepła Bez względu na to z jakiego powodu jakieś rozwiązanie jest "złe" czy też "gorsze" to musi za tym przemawiać jakaś korzyść dla drugiego rozwiązania. Dopóki ja nie zrozumiem tej korzyści to będę pisał tak jak mi wygodniej i myślę że nie tylko ja tak mam (korzyścią może być choćby to że będę pisał tak jak wszyscy inni dzięki czemu łatwiej jest współpracować - ale wszyscy inni pewnie nie piszą w taki sposób żeby dopasować się do wszystkich innych)
Zdaje sobie sprawę z różnych kryteriów optymalizacji.

mokrowski masz bardzo ciekawe podejście. Wydaje się ono całkiem słuszne, ale...
niestety jestem taką istoto która sama musi popełnić wszystkie możliwe błędy - jeśli ktoś mi powie o problemie a ja nie zrozumiem tego w pełni to pewnie nie uznam to za możliwe w moim specyficznym przypadku

Faktycznie ciekawie wygląda plik *.lss z kodem C ale ma to raczej znaczenie przy większych projektach.
jeśli chodzi o zabawę w asemblera to chyba już starczy na dzisiaj bo na jutro nie zostawie sobie niczego do odkrywania

ale jeśli chodzi o optymalizację tych funkcji o czym wspominałeś faktycznie udało się przy optymalizacji -O2 chyba dopiero ale zawsze no i niestety zaskoczenie było niewielkie bo wszystko było już zaspoilowane

odnośnie call - tak jak pisałem w na koniec wynikało to z kompilowania dla atmegi16 a patrzenia w specyfikację atmegi8 i tak jak pisałem było to tak jak napisałem informacje znalazłem w specyfikacji atmegi8 (podejrzewam że dowolna młodsza niż z 2003 roku będzie miała tą informację) i tutaj masz bezpośredni link do strony atmela (strona 322)
http://www.atmel.com/Images/Atmel-2486-8-bit-AVR-microcontroller-ATmega8_L_datasheet.pdf

odnośnie mojej wspaniałej optymalizacji... okazało się że nie ma problemu aby podzielić częstotliwość przerwania ... wielokrotnie - i tym optymistycznym akcentem

edit. aaa Mirku! odnośnie asemblera - kazali mi się nauczyć to znam (a przynajmniej znam zasady), pisałem w tym wystarczająco długo żeby trzymać klawiaturę za oknem- czyli jakieś 100 linijek swoją drogą bezprzewodowa klawiatura dla programisty to chyba ostatecznie zły wybór Ale czasem fajnie jest wiedzieć "co w trawie piszczy" choćby po to żeby przeanalizować jak działa przedrostek volatile jak to pokazujesz na blogu co miałem przyjemność dzisiaj czytać

Statystyki: Napisane przez rekon — 22 lut 2015, o 21:24

Re: Łączenie warunków

2015-02-22T14:56:48+01:00

rekon napisał(a):

ale być może nie rozumiem wyższości tych funkcji z tego poziomu.

Być może się mylę ale ...

po pierwsze nie chodzi tu o wyższość jednego rodzaju funkcji nad drugą w sensie stricte np zajętości pamięci Flash. Nie zawsze optymalizacja kodu wiąże się TYLKO przecież z ilością kodu we flash, czasem wiąże się właśnie z CZASEM wykonywania i wtedy godzimy się nawet na to żeby zajętość FLASH była większa ....

ale czasem - i to bywa chyba NAJWAŻNIEJSZE ... optymalizujemy kod pod kątem przyszłego użycia, hmmm stylu programowania, bo ważniejsze jest nie to jak dużo kod zajmie (można wziąć przecież procka z większą pamięcią flash) .... ale na ile kod będzie czytelny nawet po 10 latach gdy do niego sięgniemy albo jak wyżej pisał kolega na ile łatwo będzie w takim kodzie odnaleźć błędy ... i to (wydaje mi się) chcieli także koledzy wyżej przekazać ....

dodatkowo warto zwrócić uwagę na to ... że język C to nie asembler a często zapominają o tym osoby mocno związane z asemblerem i próbują rozpatrywać nawet prosty kod pod kątem każdej najbardziej niskopoziomowej instrukcji procesora gdy tymczasem najczęściej nie ma to najmniejszego znaczenia - że kod wykona się w 2 czy w 5 cyklach zegara. To jest też taki właśnie przypadek ( tak mi się wydaje - zaznaczam ) ....

Jak widać kwestii czytelności kodu (dobrego stylu programowania) nigdy nie rozwiążemy poprzez zmianę procka ale już brak pamięci flash, ram czy eeprom spokojnie tak

Na zakończenie - oczywiście bardzo fajnie jest znać asembler i umieć sobie analizować kod niskiego poziomu bo choć rzadko - to jednak być może czasem ... czasem kiedyś tam może się to przydać przecież pisząc jakiś wysoce zaawansowany w czasowe zależności projekt

Statystyki: Napisane przez mirekk36 — 22 lut 2015, o 14:56

Re: Łączenie warunków

2015-02-22T12:12:25+01:00

mokrowski odpowiadając od końca przepraszam Cię, zareagowałem bardzo nieuprzejmie conajmniej. Na swoje usprawiedliwienie mogę dodać że wczoraj był bardzo męczący dzień aczkolwiek to nie jest żadne usprawiedliwienie...
3. brak doświadczenia zdecydowanie cechuję moją osobę, w ciągu ostatnich 3 lat na studiach uczono nas programować w 6 czy 7 językach programowania więc w każdym wiem wystarczająco dużo żeby nie wytrzymywać z nudów czytając książki odnośnie języków programowania, a czasem po prostu miesza się to wszystko i zapomina się o takiej rzeczy jak "&&", a niestety pomimo iż powinni uczyć nas przede wszystkim programować sprzęt to jest to zupełnie pominięte ale za to zrobiłem już ze 3 kalkulatory ...
1-2. to o co zapytałem było elementarne i to nie tylko wg. Ciebie - jest to podstawowa operacja i tłumaczy się to wszędzie jeśli tylko wspomina się o instrukcjach warunkowych niestety dziura w głowie wyżarła tą informację, Twoja odpowiedź faktycznie była staranna i całe szczęście że są jeszcze ludzie którym się chce
Jeszcze odnośnie początkującego - jestem początkującym w AVR ale nie koniecznie w programowaniu, stąd jakaś tam chora ambicja i duma poczuła się dotknięta kiedy zwróciłeś uwagę na konwencję którą raczej znam i zwykle stosuje ale chciałem aby opis problemu był najłatwiejszy z możliwych
0. Co do GND, ehhhh >>westchnął patrząc na swoje rezystory przy przyciskach<<. "Podciąganie programowe" nawet mi nie przyszło do głowy - na szczęście. Element zaskoczenia zawsze jest pozytywny bo sprawdza czujność nawet jeśli jest zaskoczenie jest niezamierzone.

-1. Co do kodu w asemblerze dzięki za sugestię - byłem, sprawdziłem:)
Faktycznie jestem zdziwiony, ale chyba nie tak jak miałem.
Pozwolę sobie wrzucić tutaj kody w C oraz asemblera wygenerowanego z tych kodów. Dodałem jedynie coś w warunku oraz część else.
[syntax=c]#include
#include

bool switch1_pressed(void);
bool switch2_pressed(void);
bool both_switch_pressed(void);

int main(void) {
if( both_switch_pressed() ) {
DDRB |= (1< }else{
DDRB |= (1< }

while(1);
}

bool switch1_pressed(void) {
return !(PIND & ( 1 << PD0) );
}

bool switch2_pressed(void) {
return !(PIND & ( 1 << PD1 ) );
}

bool both_switch_pressed(void) {
return (switch1_pressed() && switch2_pressed() );
}[/syntax]
i odpowiadający
[syntax=asm]0000006c :
6c:80 b3 inr24, 0x10; 16
6e:80 95 comr24
70:81 70 andir24, 0x01; 1
72:08 95 ret

00000074 :
74:80 b3 inr24, 0x10; 16
76:86 95 lsrr24
78:81 70 andir24, 0x01; 1
7a:91 e0 ldir25, 0x01; 1
7c:89 27 eorr24, r25
7e:08 95 ret

00000080 :
80:0e 94 36 00 call0x6c; 0x6c
84:88 23 andr24, r24
86:19 f0 breq.+6 ; 0x8e
88:0e 94 3a 00 call0x74; 0x74
8c:02 c0 rjmp.+4 ; 0x92
8e:80 e0 ldir24, 0x00; 0
90:90 e0 ldir25, 0x00; 0
92:81 70 andir24, 0x01; 1
94:08 95 ret

00000096

:
96:0e 94 40 00 call0x80; 0x80
9a:88 23 andr24, r24
9c:11 f0 breq.+4 ; 0xa2
9e:bc 9a sbi0x17, 4; 23
a0:03 c0 rjmp.+6 ; 0xa8
a2:87 b3 inr24, 0x17; 23
a4:81 61 orir24, 0x11; 17
a6:87 bb out0x17, r24; 23
a8:ff cf rjmp.-2 ; 0xa8 [/syntax]

oraz kod oparty na define'ach

[syntax=c]#include

#define BUTT1_PRESSED !(PIND & ( 1 << PD0) )
#define BUTT2_PRESSED !(PIND & ( 1 << PD1) )
#define BOTH_BUTT_PRESSED (BUTT1_PRESSED && BUTT2_PRESSED)

int main(void) {
if( BOTH_BUTT_PRESSED ) {
DDRB |= (1< }else{
DDRB |= (1< }
while(1);
}[/syntax]

[syntax=asm]0000006c

:
6c:80 99 sbic0x10, 0; 16
6e:04 c0 rjmp.+8 ; 0x78
70:81 99 sbic0x10, 1; 16
72:02 c0 rjmp.+4 ; 0x78
74:bc 9a sbi0x17, 4; 23
76:03 c0 rjmp.+6 ; 0x7e
78:87 b3 inr24, 0x17; 23
7a:81 61 orir24, 0x11; 17
7c:87 bb out0x17, r24; 23
7e:ff cf rjmp.-2 ; 0x7e [/syntax]

Pierwsze moje zaskoczenie dotyczyło instrukcji "call", która wg. specyfikacji atmega8, jeśli dobrze zrozumiałem została usunięta w 2003 roku ze specyfikacji, szczerze powiedziawszy nie wiem co ma to oznaczać tak dokładnie. W sumie zastanawiam się dlaczego usunięto tą instrukcję oraz dlaczego w takim razie kompilator nadal tego używa.

Quote:

Removed instructions CALL and JMP from the datasheet.

Kolejna rzecz która mi się podoba w rozwiązaniu z "define" to fakt że omija wszystkie inne warunki jeśli pierwszy powoduje, iż całość się nie powiedzie od razu przeskakując do części else. Poza tym w tych listingach jest mniej więcej to czego się spodziewałem, ale być może nie rozumiem wyższości tych funkcji z tego poziomu.

Postanowiłem jeszcze sprawdzić taki kod, który z punktu widzenia człowieka jest oczywiście bez sensu i aż się prosi aby napisać to lepiej, ale w celach edukacyjnych test odnośnie jakichś usprawnień (wiem że jest to związane z wybranym kompilatorem itd. ale chciałem sprawdzić co się dzieje domyślnie).
[syntax=c]int main(void) {
if (both_switch_pressed()) {
DDRB |= (1< }else{
DDRB |= (1< }

if (both_switch_pressed()) {
DDRC |= (1< }else{
DDRC |= (1< }
while (1);
}[/syntax]

Daje kod wynikowy

[syntax=asm]00000096

:
96:0e 94 40 00 call0x80; 0x80
9a:88 23 andr24, r24
9c:11 f0 breq.+4 ; 0xa2
9e:bc 9a sbi0x17, 4; 23
a0:03 c0 rjmp.+6 ; 0xa8
a2:87 b3 inr24, 0x17; 23
a4:81 61 orir24, 0x11; 17
a6:87 bb out0x17, r24; 23
a8:0e 94 40 00 call0x80; 0x80
ac:88 23 andr24, r24
ae:11 f0 breq.+4 ; 0xb4
b0:a4 9a sbi0x14, 4; 20
b2:03 c0 rjmp.+6 ; 0xba
b4:84 b3 inr24, 0x14; 20
b6:81 61 orir24, 0x11; 17
b8:84 bb out0x14, r24; 20
ba:ff cf rjmp.-2 ; 0xba [/syntax]

No i na koniec jest chyba jedno rozwiązanie, które w jakiś tam sposób pogodzi te 2 różne opcje, rozwiązanie które nie wykorzystuje instrukcji call i ret a mimo wszystko daje to możliwości debugowania o czym wspomina PJS. A tym rozwiązaniem są po prostu funkcje z przedrostkiem inline. W takim przypadku wilk syty i owca cała - chyba.

Dziękuję panom za chęci pomocy pomimo mojej postawy.

Podczas pisania posta (które zajęło dość długo) dostałem ostrzeżenie, przyjmę z pokorą. Mam nadzieję, że będzie mi dane "odpracować w polu" moje zachowanie.

edit. Odnośnie mojego zdziwienia funkcją "call" zdziwienie było spowodowane tym że program był kompilowany pod atmege 16, a specyfikacja w którą patrzyłem była dla atmegi 8 ... po sprawdzeniu kodu wynikowego dla atmegi 8 wszystko w porządku jeśli o to chodzi.

Statystyki: Napisane przez rekon — 22 lut 2015, o 12:12

Re: Łączenie warunków

2015-02-22T10:39:59+01:00

rekon napisał(a):

ale mam wrażenie, że było to odrobinę "nadopiekuńcze" i jeszcze w dodatku nie spełniało jakiś tam moich założeń

Być może kolega ma jakieś "dziwne" hmmm wręcz chore przyzwyczajenia z innych forów... np z ele. Gdzie nie jest ważne wyjaśnienie dogłębne, nie jest ważna przyjacielska atmosfera tylko jakieś bezsensowne trzymanie się tematu - podczas gdy często autor pytania często nawet nie zdaje sobie sprawy że np idzie złą drogą, gdy ktoś chce mu pokazać szerszy aspekt problemu ...
Zawsze powtarzam, że warto pomagać nawet gdy się popełni jakiś błąd - bo inni (którzy akurat wiedzą więcej chętnie poprawią i zrobią to kulturalnie - dlatego na naszym forum także często pomagają całkowicie początkujący ....)
A tu nomen omen tak się akurat tobie trafiło że dostałeś odpowiedź i to jeszcze jaką! od na prawdę wysokiej klasy specjalisty, który świetnie przedstawił wszystko co trzeba i poza tobą jeszcze wiele innych osób może skorzystać z takiej odpowiedzi czytając w przyszłości ten post ...

REASUMUJĄC - panie kolego rekon .... rzadko udzielam ostrzeżeń na forum (to się chyba WARN nazywa) ale w tym przypadku to robię i proszę na przyszłość dostosować się do zasad naszego forum .... i działać z nami - serdecznie zapraszam. W przeciwnym wypadku - po co się tu z nami męczyć ?

Statystyki: Napisane przez mirekk36 — 22 lut 2015, o 10:39

Re: Łączenie warunków

2015-02-21T20:33:45+01:00

rekon napisał(a):

Nie tylko przyjemnie się czyta ale i debuguje, co przy twoim rozwiązaniu z define jest problematyczne. O ile w przypadku prostego programu to różnic nie będzie, to szukanie przyczyny wadliwego działania w trochę bardziej zaawansowanym programie już jest znacznie mniej przyjemne. A teraz przypuśćmy, że masz uszkodzony przycisk - jak namierzysz w programie opartym na define'ach ten "problem"? Z funkcjami po prostu lecisz krokowo w debugerze i już.
A co do optymalizacji, to kompilator prawdopodobnie (tu wszystko zależy od ustawień optymalizacji kompilatora) wygeneruje tak samo wydajny kod. Wbrew pozorom twórcy kompilatorów potrafią uwzględnić takie "puste/niepotrzebne" przebiegi funkcji.

Statystyki: Napisane przez PJS — 21 lut 2015, o 20:33

Re: Łączenie warunków

2015-02-21T19:50:27+01:00

@mokrowski serio?? - w sensie zgadzam się z Tobą taki kod bardzo przyjemnie się czyta i edycja dzięki temu jest niesamowicie prosta...
ale nie wiem czy nie przeczytałeś czy o co chodzi ale zależało mi na zmniejszeniu liczby cykli ... a to co zaproponowałeś jest chyba jednym z mniej optymalnych rozwiązań z możliwych ...

osobiście uważam że rozwiązaniem 10 razy lepszym byłoby robienie na definicjach preprocesora jak już się w to bawimy i wtedy

[syntax=c]#define BUTT1_PRESSED (PIND & ( 1 << PD0) )
#define BUTT2_PRESSED (PIND & ( 1 << PD1) )
#define BOTH_BUTT_PRESSED (BUTT1_PRESSED && BUTT2_PRESSED)

int main(void) {
if( BOTH_BUTT_PRESSED ) {
/* Operacja wykonywana w przypadku wciśnięcia 2 przycisków */
}
}[/syntax]

i przynajmniej nie wywołujesz funkcji które robią nic
ale zupełnie nie o to było pytanie ...
zresztą wydawało to o czym pisałem na początku to tak jak zaznaczyłem to był jedynie przykład (tak jak z warunkiem 1 == 1)
bardzo się cieszę że chcesz się podzielić swoją wiedzą i bardzo się cieszę że Ci się chce odpisywać innym, ale mam wrażenie, że było to odrobinę "nadopiekuńcze" i jeszcze w dodatku nie spełniało jakiś tam moich założeń

btw. jakiś konkretny powód dla którego przyciski do GND czy "tak się po prostu robi"?

Statystyki: Napisane przez rekon — 21 lut 2015, o 19:50

Re: Łączenie warunków

2015-02-21T13:02:11+01:00

[syntax=c]if (PIND &((1<
jak się nie mylę

Statystyki: Napisane przez Rafał555 — 21 lut 2015, o 13:02

Re: Łączenie warunków

2015-02-21T11:05:50+01:00

hahaha oczywiście - coś tam dzwoniło w uszach że przecież to oczywiste ale nie mogłem sobie przypomnieć
tak to jest jak się zbyt długo robi w językach wyższego poziomu ...
dzięki

edit. bardzo smaczna i zdrowa ryba

Statystyki: Napisane przez rekon — 21 lut 2015, o 11:05

Re: Łączenie warunków

2015-02-21T10:56:19+01:00

panie kolego podstawy C

operatory bitowe

& |

a tu operatory logiczne

&& ||

rozumiesz ?

czyli

[syntax=c]if( warunek1 && warunek2 )[/syntax]

Statystyki: Napisane przez mirekk36 — 21 lut 2015, o 10:56

Łączenie warunków

2015-02-21T10:53:15+01:00

Witam mam problem z łączeniem warunków, tzn. np chciałbym aby dioda LED się zapaliła tylko jeśli przycisk pod PD0 oraz PD1 będzie wciśnięty
oczywiście można zrobić to w taki sposób
[syntax=c]if(PIND & (1 << PD0))
if(PIND & (1 << PD1))
LED_ON;[/syntax]
ale nie chciałbym tak robić ze względu na to iż jest tutaj o co najmniej jednego "ifa" za dużo, a ponieważ mam zamiar użyć podobnej konstrukcji w przerwaniu które wyszło mi STRASZNIE opasłe to może się to okazać kluczowe... a poza tym nie wydaje się aby to było optymalne...

szukałbym czegoś w stylu

[syntax=c]if((PIND & (1 << PD0)) & (PIND & (1 << PD1)))
LED_ON;[/syntax]

tylko że oczywiście powyższe nie zadziała bo uzyskamy (0x01 & 0x02) = 0
tak samo jest jeśli chciałbym aby dioda się zapaliła tylko jeśli 1 jest równe 1 (albo dowolny inny warunek arytmetyczny) a przycisk pod PD1 jest wciśnięty. Poniższy kod również nie zadziała.
[syntax=c]if( (1 == 1) & (PIND & (1 << PD1)))
LED_ON;[/syntax]

oczywiście można się bawić w przesunięcia w stylu

[syntax=c]if( (1 == 1) & (PIND & (1 << PD1)) >> PD1)
LED_ON;[/syntax]
ale nie wiem czy jest to "ładne" pomimo że powinno działać

czy jest jakiś "elegancki" sposób na robienie tego typu złożonych warunków??

Statystyki: Napisane przez rekon — 21 lut 2015, o 10:53