Witam, od dawna programuję w języku asemblera nieprodukowane już procesory typu 89C51. Chciałbym jednak przejść na język C i na AVRy np: Atmega8, a to wszystko z oczywistych względów tj. bogatsza architektura wewnętrzna jaką mają AVRy w porównaniu z przestarzałą 51 z tego co słyszałem to C jest prostszym językiem niż asembler ale jak zmienić tu tok myślenia podczas pisania programu. Do tej pory pisząc w asemblerze znałem architekturę wewnętrzną danego procesora i odwoływałem się do danego rejestru, proste i td,. A jak to wygląda pisząc w języku C, czy trzeba również znać architekturę wewnętrzną danego procesora, czy pisze się jakoś ogólnie? słyszałem tez o książce pt: ''Język C dla mikrokontrolerów AVR. Od podstaw do zaawansowanych aplikacji''Tomasz Francuz. Czy ktoś posiada tą książkę? Opłaca się ją nabyć? Zaczynam trochę żałować że od początku nie zacząłem programować w C,..
Żałować nie masz czego, wręcz przeciwnie, znajomość asemblera ZDECYDOWANIE i to bez DWÓCH zdań przyda ci się przy programowaniu w C. Podkreślam zdecydowanie - zobaczysz
Kolego byłem w dokładnie takiej samej sytuacji jak Ty i odnoszę wrażenia że nie wykonałeś żadnego kroku w kierunku poznania avr. Proponuję Ci abyś na początek poznał architekturę AVR i pisał programy w asm a później po zapoznaniu się z architekturą przesiadł się na C. Do poznania budowy AVR wystarczy Ci nota aplikacyjna dowolnego AVRa. Dodatkowo zapoznaj się też z książkami Pana Dolińskiego i/lub Baranowskiego.
Ja polecam książkę Mirosława Kardasia (mirekk36, link w podpisie 2 posty wyżej), masz tam wyjaśnione podstawy języka C i pracy z mikrokontrolerami AVR.
Książka Tomka Francuza też jest dobra, porusza dużo dosyć zaawansowanych kwestii związanych z AVR i jeśli masz już jakieś ogólne pojęcie o C i elektronice oraz programowaniu to powinieneś dać z nią też radę.
Witam, od dawna programuję w języku asemblera nieprodukowane już procesory typu 89C51. Chciałbym jednak przejść na język C i na AVRy np: Atmega8, a to wszystko z oczywistych względów tj. bogatsza architektura wewnętrzna jaką mają AVRy w porównaniu z przestarzałą 51 z tego co słyszałem to C jest prostszym językiem niż asembler ale jak zmienić tu tok myślenia podczas pisania programu. Do tej pory pisząc w asemblerze znałem architekturę wewnętrzną danego procesora i odwoływałem się do danego rejestru, proste i td,. A jak to wygląda pisząc w języku C, czy trzeba również znać architekturę wewnętrzną danego procesora, czy pisze się jakoś ogólnie? słyszałem tez o książce pt: ''Język C dla mikrokontrolerów AVR. Od podstaw do zaawansowanych aplikacji''Tomasz Francuz. Czy ktoś posiada tą książkę? Opłaca się ją nabyć? Zaczynam trochę żałować że od początku nie zacząłem programować w C,..
Do tej pory pisząc w asemblerze znałem architekturę wewnętrzną danego procesora i odwoływałem się do danego rejestru
W C jest dokładnie to samo Tylko że zamiast używać assemblerowych instrukcji i operowania na rejestrach roboczych, piszesz "równaniami" w stylu REJESTR = (1<<BIT) i nic Cię więcej nie obchodzi. Może to z początku wyglądać dziwnie, ale do wszystkiego da się przyzwyczaić.
Dokładnie. Poza tym w C masz sprawę ułatwioną. Zamiast samemu pisać procedury na np. mnożenie liczb, zastanawianie się jak i skąd mają być wczytane, do jakich rejestrów, piszesz po prostu: a=b*10;
C jest moim zdaniem dużo prostszy od ASM w pisaniu kodu, bo działasz na wyższym poziomie. Ale jak sam napisałeś i tak trzeba poznać sprzęt==poczytać dokumentację procesora, na którym będziesz się uczył.
Kup sobie ksiazke: cwiczenia praktyczne w jezyku C. Kosztuje kolo 15zl.. Usiadz w weekend, przerob kilka zadan i bedziesz wiedzial czy taka filozogia tworzenia oprogramowania Ci odpowiada.... Najprostsza i najtansza metoda. Jak juz bedziesz umial podstawy tego jezyka to dopiero wtedy bierze sie za AVR/ARM.
Natomiast co do dwoch ksiazke, ktore wymieniles to kwestia gustu. Najlepiej isc do biblioteki, poczytac i sie zastanowic. Na tym forum panuje opinia: Kardas dla poczatkujacych, Francuz dla sredniozawansowanych. Jednak pamietaj, ze zadna z tych ksiazek nie nauczy Cie samego jezyka C. Dlaczego? Wtedy by musiala miec grubo ponad 2k stron....
Chyba w celu utrwalania niskopoziomowych nawyków starając się przechytrzyć kompilator (;
Pewnie. A później amatorzy programowania dzięki takiemu podejściu zapisują proste zmienne jako float albo nie wiedzą jaka jest różnica dla działania programu pomiędzy dzieleniem przez 8 a dzieleniem przez 9. Wiedza o asemblerze jeszcze nikomu nie zaszkodziła czego nie można powiedzieć o niewiedzy.
Pewnie. A później amatorzy programowania dzięki takiemu podejściu zapisują proste zmienne jako float albo nie wiedzą jaka jest różnica dla działania programu pomiędzy dzieleniem przez 8 a dzieleniem przez 9. Wiedza o asemblerze jeszcze nikomu nie zaszkodziła czego nie można powiedzieć o niewiedzy.
Odpowiedziałbym jednak cytatem, że "premature optimization is the root of all evil" (; A może z tymi floatami jednak się wyrobi (sprawdzałeś, czy jak większość zakładasz że na pewno nie?), a może właśnie zamiast dzielić przez 8 ktoś musi dzielić przez 9 i wymyślanie przez pół dnia algorytmu który zaoszczędzi 1ms dziennie nie ma sensu? (; Trochę luzu [; Również w sprawie floatów, bo wbrew pozorom do wielu zastosowań są "wystarczająco szybkie", nawet na AVR (; Przykład? Jeśli masz użytkownikowi pokazać wynik obliczeń na LCD to co za różnica czy będzie musiał poczekać na niego 1us czy 1ms?
Do tego żeby wiedzieć czy float jest "za ciężki" czy nie, nie trzeba wcale być mistrzem assemblera, wystarczy pomyśleć przez 15 sekund.
Nie mówiąc już o tym, że używając na początku float można od razu otrzymać poprawny wynik, a potem na zasadzie porównania dojść do algorytmu bez liczb zmiennoprzecinkowych (jeśli w ogóle jest potrzeba - patrz cytat). A że niektórzy od razu wolą optymalizować wszystko, nawet jak nie ma to sensu...
Od razu dodam, że jak ktoś musi oszczędzać pamięć, bo już się kończy (lub ma pewność że się skończy w w trakcie rozbudowy programu), to taka "optimization" nie jest "premature". Co innego jak ktoś pisze program który zajmie 20kB na układ który ma 128kB pamięci, ale profilaktycznie oszczędza każdy bajt...
Z drugiej zaś strony jak ktoś jest prawdziwym h4x0rem to np zamiast napisać tak:
a = tablica((++i) % 8);
będzie pisał tak:
a = tablica[(++i) & 7];
tylko na podstawie błędnego założenia, że kompilator by sam na to nie wpadł, obniżając czytelność programu. Albo jeszcze lepszy przykład dla prawdziwych optimization-masters:
if (zmienna & 0x80) // załózmy że zmienna jest int8_t
no i co to niby znaczy? O co tu chodzi? Równoważny kod:
if (zmienna < 0)
tutaj również kompilator by na to sam nie wpadł, wiec trzeba mu "pomóc".
Na zakończenie powiem tyle - jak ktoś uważa, że kompilatorowi trzeba pomagać optymalizować program w takich bzdurnych miejscach, to niech zrobi dwie rzeczy:
1. podejrzy assemblera wygenerowanego przez kompilator w obydwóch przypadkach (oczywiście na włączonej optymalizacji) i stwierdzi czy jest różnica na "+" dla wersji trV-h4x0r
2. przeczyta sobie ten tekst - http://c2.com/cgi/wiki?PrematureOptimization
Dla kompletności podaję KOMPLETNY cytat:
Cytat:
There is no doubt that the grail of effi-
ciency leads to abuse. Programmers waste
enormous amounts of time thinking about,
or worrying about, the speed of noncritical
parts of their programs, and these attempts
at efficiency actually have a strong negative
impact when debugging and maintenance are
considered. We should forget about small
efficiencies, say about 97% of the time: pre-
mature optimization is the root of all evil.
Yet we should not pass up our opportuni-
ties in that critical 3 %. A good programmer
will not be lulled into complacency by such
reasoning, he will be wise to look carefully
at the critical code; but only after that code
has been identified. It is often a mistake to
make a priori judgments about what parts
of a program are really critical, since the
universal experience of programmers who
have been using measurement tools has been
that their intuitive guesses fail.
Jak zwykle masz rację Dodam tylko, że jeśli ktoś wziął do projektu procek z 16 kB FLASH, a okazuje się, że potrzebuje 32 kB lub więcej to po prostu popełnił błąd na wstępie, a dalej to jest tylko maskowanie błędu a nie optymalizacja. Druga kwestia - często początkujący mają problem z odróżnieniem optymalizacji od dobrych praktyk programowania. Jeśli ktoś od początku robi obliczenia korzystając ze stałego przecinka (tam gdzie ma to uzasadnienie), to nie jest optymalizacja, tylko po prostu dobra praktyka - właściwy dobór narzędzi do rozwiązania problemu. Jeśli ktoś na procku ze 128kB pisze program, który zajmie 20 kB i kombinuje jak go skrócić to jest to głupota.
Asembler się przydaje, jak każda wiedza. Z pewnością ułatwia debugowanie kodu, ale czy jego pisanie w językach wyższego poziomu? Wątpię. Chyba, że tak jak piszesz, ktoś podnieca się tym, że wymyślił jak coś napisać w asemblerze prościej/krócej i musi się dowartościować, że jednak jest lepszy niż kompilator Tyle, że co z tego? Zrobić wstawkę w asemblerze?
Kiedyś język C miałem na studium informatycznym, ale były to zaledwie kilka godzin podstaw, kojarzę tylko jakąś "pętle if" i tp. Po za tym nic mi do głowy więcej nie weszło bo wtedy nie miałem zamiaru głowy sobie zawracać innym językiem skoro miałem opanowany już asembler, ale nie wiedziałem o tym że pod każdą inną rodzinę mikrokontrolerów będę musiał uczyć się nowych mnemoników. Dodatkowo znajomość języka C zawsze się kiedyś może jeszcze przydać nie tylko w mikrokontrolerach. Tak na prawdę jeszcze nie zrobiłem żadnego kroku w kierunku języka C ale pomału się przymierzam. Na początek przeanalizuję podane przez was stronki i zobaczę co z tego będzie.
Jeśli chodzi o programowanie samej kości to posiadam programator willem programować mogę nim między innymi: AVR 90S4433 i z tego co zauważyłem ma on takie same wejścia/wyjścia jak atmega8, czy w związku z tym będę mógł zaprogramować nim atmega8?
Jeśli chodzi o programowanie samej kości to posiadam programator willem programować mogę nim między innymi: AVR 90S4433 i z tego co zauważyłem ma on takie same wejścia/wyjścia jak atmega8, czy w związku z tym będę mógł zaprogramować nim atmega8?
Nie wiem, jedno i drugie to staroć. Chcesz zostać kustoszem w jakimś muzeum techniki?
Kup sobie porządny AVRISP MkII (klon lub oryginał), co najmniej ATMega88 lub lepiej jakiś XMEGA, albo kup sobie Xplained, nie będziesz potrzebował programatora i zacznij się bawić. Albo po prostu zainstaluj darmowe Atmel Studio i odpalaj przykłady w symulatorze - początek masz za darmo, a potem już będziesz wiedział co kupić.
Kiedyś język C miałem na studium informatycznym, ale były to zaledwie kilka godzin podstaw, kojarzę tylko jakąś "pętle if" i tp. Po za tym nic mi do głowy więcej nie weszło... Tak na prawdę jeszcze nie zrobiłem żadnego kroku w kierunku języka C ale pomału się przymierzam. Na początek przeanalizuję podane przez was stronki i zobaczę co z tego będzie.
Do tego żeby wiedzieć czy float jest "za ciężki" czy nie, nie trzeba wcale być mistrzem assemblera, wystarczy pomyśleć przez 15 sekund.
Nie mówiąc już o tym, że używając na początku float można od razu otrzymać poprawny wynik
Od jak piszesz ciężaru arytmetyki zmienno przecinkowej istotniejsze zwłaszcza dla początkującego są niuanse typu że 3 to czasami nie jest równe 2* 1.5, utrata precyzji obliczeń, akumulacja błędów obliczeniowych i tym podobne.
To bywa trudne do oceny nie tylko na początkowym etapie.
Tak więc bym z tym poprawnym wynikiem był ostrożniejszy