Witam,

Czy macie pomysł na "wizualny" zapis np. DDRB = 0xff ?
W Bascomie można stosować wizualne rozdzielenie np:
Config Portb = &B___1___1___0____1___0___1___1____1

, gdzie szybko można zauważyć poszczególne bity, lub np. podpisać pod spodem.

Jak to można zrobić w AVR GCC ?

Pozdrawiam.

Dlaczego taki słabo widoczny kolor?

Poprawione - Różowy J.

W C robi się to równie prosto



ale jeśli chcesz ustawić np tylko ze 2-3 albo jeden bit to JESZCZE LEPIEJ zobacz i sam domyślisz się które piny ustawiam na 1 po resecie



PB6, PB2 i PB1 ustawiamy na JEDEN

chcesz je wyzerować ? to:

_________________
zapraszam na blog: http://www.mirekk36.blogspot.com (mój nick Skype: mirekk36 ) [ obejrzyj Kurs EAGLE ] [ mój kanał YT TV www.youtube.com/mirekk36 ]

Już poznałem powyższy zapis.
Jednak:
PORTB = 0b11010111;
PORTB |= (1<<PB6)|(1<<PB2)|(1<<PB1);

przyznasz, że nie wygląda tak dobrze i praktycznie jak:
Config Portb = &B___1___1___0___1___0___1___1___1

np.:

Jak widać po spojrzeniu do kodu, natychmiast można zobaczyć z czym są połączone.

Oj tam, kwestia przyzwyczajenia.

Przecież w komentarzu też możesz dać:

_________________
http://www.jaglarz.info

Dla mnie to najwygodniejszy jest zapis za pomocą define



A potem w programie po co mam pamiętać jakie porty?


A jak trzeba będzie przepiąć diodke, albo zmienic port, to wystarczy zmiana w jednym miejscu działa.

Tzn nie za bardzo rozumiem do czego dążysz ? chcesz mnie przekonać, że w Bascomie się wygodniej pisze ? .... to sorki ale ci się nie uda, mnie na pewno wygodniej się pisze w C pomimo iż kiedyś sporo robiłem w Bascomie więc mam porównanie. Absolutnie przy tym nie twierdzę, że jeden język jest lepszy od drugiego ... tylko nie rozumiem tego wątku zabardzo

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

tym bardziej, że można jeszcze prościej za pomocą makr jak wyżej napisał kolega rezasurmar

PORTB |= LED1 | LED2 | LED7;

_________________
zapraszam na blog: http://www.mirekk36.blogspot.com (mój nick Skype: mirekk36 ) [ obejrzyj Kurs EAGLE ] [ mój kanał YT TV www.youtube.com/mirekk36 ]

Na pewno, zawsze można zmienić przyzwyczajenia, ale na pierwszy plan zawsze najpierw stawia się możliwość dostosowania programu do człowieka, a nie człowieka do programu

Co do zapisu w komentarzu, to tu istnieje zbyt duże ryzyko...

Z tym #define to może być ciekawy pomysł. Jednak jak dostosować to do "mojej" wersji zapisu ?

mirekk36 czy ja gdzieś napisałem, że Bascom jest lepszy ? Napisałem, że wygodniej "moim" sposobem opisuje się porty.

Właśnie zaczynam trenować pisanie w C, więc dalej czekam na propozycje

PS

Z tym się nie zgodzę (min. 2 zmiany).

A moim zdaniem to jest nieco inaczej.

Nie chodzi o to żeby mieć te same przyzwyczajenia i żeby ktoś wymyślał tak aby wszystkie języki świata działały w ten sam sposób w kodzie bo wszystkie musiałyby być Bascomem/Basicem np dla ciebie ...

zmiana języka to zawsze - i to bez dwóch zdań zmiana przyzwyczajeń .... jeśli ktoś tego nie rozumie to niestety nie zmieni języka, bo wydaje mu się, że to co oferuje jego obecny język jest najlepsze (tzn jeśli chodzi o te przyzwyczajenia) tymczasem nie masz porównania bo nie znasz jeszcze tych innych języków.

Więc myślę, że warto czasem chociaż na chwilę oderwać się od przyzwyczajeń i spróbować pomyśleć tak jak to narzuca inny język - nie ważne czy C czy Java czy PHP czy HTML

choćby było to męczarnią - na początku - ale dopiero potem będziesz w stanie ocenić co jest dla ciebie najbardziej wygodne. I wcale nie mówię że zaraz byłby to C - być może pozostałbyś przy Bascomie ... co za problem ...

Nie mniej jednak z praktyki wiem, że wiele osób, które próbują przejść z bascoma na C i kurczowo próbują się trzymać tych nawyków z Bascoma to tym trudniej im przejść na ten C i go zrozumieć.

A wiem to z autopsji sam (wszędzie o tym piszę) aż 8 RAZY !!! podchodziłem do nauki C ... i 7 razy mnie odrzucało (a z PC'tów jestem pascalowcem) .... Więc nie mów że ciebie nie rozumiem bo rozumiem...

ale dlatego podpowiadam - że dopiero gdy się zaparłem i odłożyłem swoje fochy do rzekomo dziwnych rzeczy w C ... i je zrozumiałem - to po niedługim czasie nawet na PC odechciewa mi się już Pascala i muszę przejść na coś C podobnego czyli albo na C# albo na C++

A i na naszym forum jest wiele wątków, gdzie gdy ktoś z uporem godnym podziwu wszystko w C próbuje zrozumieć przez pryzmat Bascoma - to jest UDRĘKA/MASAKRA/ i zgroza .... oj ciężko ....

więc ani tobie nic nie zarzucam ani nie wmawiam ci że twój sposób jest jakiś tam gorszy od tego w C ... bo po co ? ... Chcesz to przejdziesz na C - nie chcesz to zostaniesz w Bascomie i też sobie pewnie poradzisz ...

_________________
zapraszam na blog: http://www.mirekk36.blogspot.com (mój nick Skype: mirekk36 ) [ obejrzyj Kurs EAGLE ] [ mój kanał YT TV www.youtube.com/mirekk36 ]

Można jeszcze prościej z zastosowaniem makr upraszających od Mirka


Wtedy nawet całej nazwy portu nie trzeba pisać tylko wystarczy ostatnią literkę.

Po za tym nie rozumiem, gdzie wygoda w rozwiązaniu bascomowym?

Dla mnie nazywanie jakichkolwiek portów bez możliwości nadania im nazw pasujących zależnie od sytuacji, vide LED_ON itd. to nie jest wcale ani wygodne ani czytelne. Bo nie raz już miałem potrzebę przeniesienia sterowania ledem, czy klawiszem z jednego wyprowadzenia na inne.
I chodziło mi o to że w jednym miejscu zmieniasz, nawet jak dwie linijki, jedna pod drugą, to nadal w programie nie grzebiesz, nadal używanie jest intuicyjne.
I nie mówię, że to rozwiązanie jest najlepsze, ot mnie one najbardziej odpowiada, bo jest przyjazne człowiekowi, zero jakiś suchych nazw Portów, można wrzucać całe definicje rozkazów etc. do definenów.

Może się mylę ale z tego co pamiętam to czytałem gdzieś że spacje są ignorowane przez kompilator więc jeśli chcesz mieć bardziej czytelnie to możesz sobie porobić odstępy pomiędzy cyframi i je pod spodem okomentować.

_________________
1, 1, 2, 5, 14, 42, 132, 429, 1430, 4862, 16796

Powyższy pomysł byłby optymalny, tylko że spacji ( DDRB = 0b01 01 0110; ) kompilator nie toleruje.

rezasurmar pokazał:


Czy w tym zapisie i ustawianiu portów znacznie zwiększa się objętość kodu ?

DDRB=0b01010110; - zajmuje 4Bajty

Definicje preprocesora nie mają znaczenia na długość kodu wynikowego.(no może poniekąd) Można powiedzieć on tylko przygotowuje kod do kompilacji - ale o tym jak i co, można przeczytać w bluebook'u o ile dobrze pamiętam.

A nawet jeśli zajmie Ci troszkę więcej? Stanie się coś? Świat się zawali? Póki nie brakuje Ci pamięci w procku to pisz tak, żeby było przejrzyście, żebyś otworzył kod za pół roku i wiedział co autor miał na myśli. A gdy braknie pamięci, szukaj wtedy sposobu na optymalizację.

_________________
sig off ;(

I to jest prawda, ale pytałem:
Czy w tym zapisie i ustawianiu portów znacznie zwiększa się objętość kodu ?

Poza tym, jak w nim szybko ustawić DDRC dla poszczególnych pinów ?

Nie mam pojęcia o objętość kodu, nigdy się nad tym nie zastanawiałem.

Jak szybko ustawić?



lub z definicją preprocesora, tak żebyś wiedział od razu co robisz:

_________________
sig off ;(

Dlaczego w zapisie: #define LED (1<<PC3) kompilator wyrzuca:



Czy zapis: #include <avr/io.h> nie wystarczy ?

Jakie środowisko? Czy wybrałeś procesor na jaki ma to być skompilowane?

------------------------ [ Dodano po: 2 minutach ]

Teraz zobaczyłem na numer linii.

Definicje dla preprocesora to raczej na górze pliku, najlepiej w pliku nagłówkowym .h ale do testów może być nawet w main.c jak chcesz, byle na początku po include

_________________
sig off ;(

W Eclipse przy otwieraniu projektu został wybrany procesor i częstotliwość kwarcu.

Chcesz powiedzieć, że ten kod który wstawiłeś nie kompiluje się?
Naciśnij ctrl i kliknij w PC3 i zobacz czy przeniesie Cię do pliku nagłówkowego
Tak samo z DDRC

_________________
sig off ;(

chomiken --> czy zaczniesz w końcu stosować ???

[ syntax = c ]

zamiast tego [ code ]

przecież NIC nie widać

_________________
zapraszam na blog: http://www.mirekk36.blogspot.com (mój nick Skype: mirekk36 ) [ obejrzyj Kurs EAGLE ] [ mój kanał YT TV www.youtube.com/mirekk36 ]

ctrl i kliknij w PC3:
"Selected text cannot be mapped to symbol name"

A masz Pan toolchaina zainstalowanego ? Bo wygląda na to, że w ogóle nie jest dołączona biblioteka.

Projekt oczywiście utworzyłeś dla AVR?
Zrobiłeś clean przez build?

_________________
sig off ;(

Mam jeszcze zainstalowanego WinAVR z przed kilku lat (długo się biorę za C na AVR).
Eclipse został kiedyś zainstalowany pod kątem Androida, z którego korzystam.
Dodałem tylko AVR_plugin_240_final.

Czy instalacja "atmel toolchain" jest konieczna ?
Jeśli zainstaluje "atmel toolchain" to WinAVR można całkowicie usunąć ? (nie lubię zaśmiecać dysku)

Nie jest konieczna. Szczególnie jeśli działasz na typowych procach. To jest nowsza wersja narzędzi bo AVR-GCC na razie się zatrzymał na wersji z 2010 roku.
Firma atmel na bazie tego projektu zrobiła swój toolchain, działający tylko w WIN.
Ale podobno ludzie od AVR-GCC coś mają "wypuścić" nowego.

Jeśli nie jest konieczna, to dlaczego nie kompiluje mi się powyższy kod ?
Czy może to mieć coś wspólnego z moją wersją WinAVR 20090313 ?

Jeśli tak, to czy można usunąć WinAVR i zostawić sam "atmel toolchain" ?

PS
Jaka jest różnica między "atmel toolchain" & WinAVR ?
Oprócz obsługi nowszych uC.

Oj to Ty masz strasznie starą wersję
WinAVR-20100110 ta jest aktualna jeśli chodzi o galąź AVR-GCC.
Toolchain Atmela, mozna zainstalować niezależnie, tylko trzeba zrobić sobie kopię Ecplisa, bo do Atmelowskiego są inne jar'y.
http://mirekk36.blogspot.com/2013/06/eclipse-winavr-i-atmel-dwa-w-jednym.html

Jak pisałem długo się przymierzałem do C na AVR

Czyli jak zrozumiałem, wystarczy sam "atmel toolchain" bez WinAVR ?

Wystarczy, ale ja bym zaczynał od AVR-GCC.
Atmelowski wymusza pewne rzeczy w składni, nawet są dość logiczne, ale wiele kodów w sieci jest pisana pod AVR-GCC i będą wywalać błędy, trzeba źródło przerabiać. np. "zmienne" w PROGMEM muszą być typu stałymi hehehe w sumie logiczne bo to flash, ale można się zdziwić.

Czyli muszę zainstalować nowszą wersję WinAVR ?
Bo jak rozumiem, tu może być przyczyna błędu "PC3".

Zapytam jeszcze raz. Czy wersja WinAVR-20100110 nie obsługuje "PC3" ?

Nie wiem jak jest w wersji 2009 AVR-GCC, ale w tej 2010 normalnie posługujesz się oznaczeniami portów PA(x), PB(x) itd.
Generalnie to zależy od pliku portpins.h. Musi być obecny, żeby takie oznaczenia portów działały.