Elektroda.pl
Elektroda.pl
X
Elektroda.pl
Proszę, dodaj wyjątek dla www.elektroda.pl do Adblock.
Dzięki temu, że oglądasz reklamy, wspierasz portal i użytkowników.

Jak przejść z asemblera na język C?

MEGUSMAN 09 Lut 2013 19:06 2472 17
  • #1 09 Lut 2013 19:06
    MEGUSMAN
    Poziom 14  

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

    0 17
  • #2 09 Lut 2013 19:14
    mirekk36
    Poziom 42  

    Ż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 ;)

    0
  • #3 09 Lut 2013 20:33
    excray
    Poziom 39  

    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.

    0
  • #4 09 Lut 2013 20:41
    Freddie Chopin
    Specjalista - Mikrokontrolery

    mirekk36 napisał:
    znajomość asemblera ZDECYDOWANIE i to bez DWÓCH zdań przyda ci się przy programowaniu w C.

    Chyba w celu utrwalania niskopoziomowych nawyków starając się przechytrzyć kompilator (;

    4\/3!!

    0
  • #5 09 Lut 2013 20:43
    piotrva
    Moderator na urlopie...

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

    0
  • #6 09 Lut 2013 21:34
    tmf
    Moderator Mikrokontrolery Projektowanie

    MEGUSMAN napisał:
    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,..


    Poczytaj to:
    http://mikrokontrolery.blogspot.com/2011/02/kurs-jezyka-c-spis-tresci.html
    i ogólnie cały blog. A potem będziesz już wiedział tyle, żeby podjąć samemu decyzje.

    0
  • #8 09 Lut 2013 23:45
    leonow32

    Poziom 30  

    MEGUSMAN napisał:
    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ć.

    Bardzo polecam blog http://mikrokontrolery.blogspot.com/ - poczytaj, jest pełno informacji jak zacząć i nie zwariować :)

    0
  • #9 10 Lut 2013 00:04
    piotrva
    Moderator na urlopie...

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

    0
  • #10 10 Lut 2013 01:39
    sorex86
    Poziom 15  

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

    Zobacz sobie:
    http://mirekk36.blogspot.com/2012/11/avr-eeprom-struktury-poradnik-do-ksiazek.html

    druga czesc tego video tutorialu,. zobaczysz mniej wiecej jak sie operuje C przy tworzeniu aplikacji na AVR.

    Te zdanie moglo by kandydowac do nagrodu roku, mimo, ze jest dopiero luty

    Freddie Chopin napisał:

    Chyba w celu utrwalania niskopoziomowych nawyków starając się przechytrzyć kompilator (;

    4\/3!!


    :D

    0
  • #11 10 Lut 2013 02:27
    excray
    Poziom 39  

    Freddie Chopin napisał:
    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.

    0
  • #12 10 Lut 2013 08:56
    Freddie Chopin
    Specjalista - Mikrokontrolery

    excray napisał:
    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.

    http://sbel.wisc.edu/Courses/ME964/Literature/knuthProgramming1974.pdf

    4\/3!!

    0
  • #13 10 Lut 2013 09:28
    tmf
    Moderator Mikrokontrolery Projektowanie

    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?:)

    0
  • #14 10 Lut 2013 10:39
    MEGUSMAN
    Poziom 14  

    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?

    0
  • #15 10 Lut 2013 10:46
    Freddie Chopin
    Specjalista - Mikrokontrolery

    sorex86 napisał:
    Te zdanie moglo by kandydowac do nagrodu roku, mimo, ze jest dopiero luty

    Ale nagroda jest w jakiej kategorii? (;

    4\/3!!

    0
  • #16 10 Lut 2013 11:12
    tmf
    Moderator Mikrokontrolery Projektowanie

    MEGUSMAN napisał:

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

    0
  • #17 10 Lut 2013 11:21
    dondu
    Moderator Mikrokontrolery Projektowanie

    MEGUSMAN napisał:
    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.

    To zacznij od kursu C z kompilatorem online CManiak: http://mikrokontrolery.blogspot.com/2011/02/kurs-jezyka-c-spis-tresci.html

    0
  • #18 11 Lut 2013 22:41
    94075
    Użytkownik usunął konto