Elektroda.pl
Elektroda.pl
X
Please add exception to AdBlock for elektroda.pl.
If you watch the ads, you support portal and users.

AVR czy Atmega ? co dla początkującego

krzycho123 27 Jul 2005 21:25 6130 28
Renex
  • #1
    krzycho123
    Level 31  
    Witam. Chciałem zacząć na poważnie obcowanie w uP . Zastanawiam się nad wejściem w aseblera lub bascoma . Wiem także że rodzina 51 wychodzi z użycia . Chciałbym raczej AVR lub Atmege. Teraz pytanie czy zamiast Atmegi w tym zestawie http://www.btc.pl/index.php?id=zl2avr moge zastosować każdego avra ?? Poradźcie mi prosze co wybrać czy raczej ten zestaw na atmedze czy zwykły 2313 http://www.btc.pl/index.php?id=zl1avr . Biore pod uwage te kity bo są to zestawy ewaluacyjne do książki , którą także chce kupić. Prosze o opinie ? Może ktoś zna inny kompleksowy system nauki uP. Bo chyba w PICi niewarto sie na początek ładować . Pozdrawiam
  • Renex
  • Helpful post
    #2
    alcon_x
    Level 14  
    Z tego co się orientuję to ATmega należy do rodziny AVR, więc to jest to samo :) Sam stawiam pierwsze kroki i wybrałem atmega8 i polecam Ci ten mikrokontroler. Programuję w C, ale nic nie stoi na przeszkodzie żeby korzystaćz innych języków :)
  • Renex
  • Helpful post
    #3
    PROGRAMISTA
    Level 12  
    Masz ciekawe pytanie AVR czy atmega :d
    Uświadomię Cię i powiem że Atmega jest bardziej rozbudowanym układem z rodziny procesorów AVR, czyli Twoje pytanie nie ma sensu

    W czym programować najlepiej w asemblerze, jeżeli masz zamiar robić w przyszłości poważne projekty! Jeżeli jako hobby to na początek najlepszy jest bascom. A co do Piców lub innej rodziny to myśle że jedne mikrokontrolery lepiej nadają się do jednego celu inne do innych celów :D
    Pozdrawiam
  • Helpful post
    #4
    przemo.t
    Level 27  
    Witam...

    Tak dla scislosci to:
    Atmega to grupa uC zaliczana do rdzenia AVR. Jak sam napisales rodzina 51' powoli jest wycofywana w nowych projektach to tez popularnego AT89Cx051 (zaliczanego do grupy 51') zastapiono uC o identycznym rozkladzie wyprowadzen tyle ze z rdzeniem AVR czyli ATTiny2313.
    ATTiny2313 to to samo tyle ze wykonane z innym szybszym rdzeniem.

    Co do zestawow ewaluacyjnych to mozesz w nie wsadzic inny procek ale koniecznie musza sie zgadzac jego wyprowadzenia z uC typowym do danego zestawu. Najbezpieczniej jest zaopatrzyc sie w przejsciowki pod uC aby mozna bylo do danego zestawu stosowac rozne uC. :|

    Co do jezykow programowania to polecam C lub bascoma, jesli nigdy wczesniej nie pisales w asemblerze to mozesz sie czasem zniechecic do prockow:|

    Pozdrawiam
  • Helpful post
    #5
    Andrzej_17
    Level 13  
    Quote:
    W czym programować najlepiej w asemblerze, jeżeli masz zamiar robić w przyszłości poważne projekty!


    To chyba jakieś żarty :D
    Kto poważny dzisiaj poważne projekty pisze w asemblerze?
    Kto się w takim olbrzymim kodzie połapie?
    Kto po przerwie będzie wiedział "co robił ten fragmencik kodu"?
    Kto w prosty sposób przeprowadzi obliczenia zmiennoprzecinkowe w asemblerze? (to tylko przykład)...


    Proszę mi wybaczyć, ale w dniu dzisiejszym pisanie większych programów to jest domena tylko i wyłącznie języków wyższego poziomu!
    Próbę pisania programu w asemblerze mogę tylko porównać do używania mechanicznej maszyny do pisania w dobie komputerów!

    Dla przypomnienia tylko podam, że procesory AVR od samego początku były projektowane z myślą o języku C, i dla niego też zostały zoptymalizowane.
    Jaki język polecam? Dla zupełnie początkujących Bascom. Faktycznie, pożera dużo pamięci, ale czy dzisiaj, w dobie procesorów z 32kB za niecałe 20zł ma to jakieś znaczenie?
    A dla poważnych programistów polecam C. Czy to darmowe WinAVR (coraz zresztą lepsze) czy jakieś komercyjne.

    Pozdrawiam wszystkich męczenników asemblerowców :D

    acha, o jednej rzeczy jeszcze wspomnę. Nie wiem czy wszyscy się orientują co oznacza skrót "Time-to-market". Otóż chodzi o czas od pomysłu na jakieś urządzenie do momentu jego wprowadzenia do produkcji. W dzisiejszym świecie, tak bardzo konkurencyjnym, w którym trzeba walczyć o pozycję na rynku, nie ma czasu na zabawę z czymś takim jak asembler... Ktoś taki zostanie po prostu zmieciony przez firmy, które potrafią korzystać z narzędzi, które istnieją:!: Maruderzy odpadają...
    Wiem, że dla hobbystów to może nie mieć znaczenia, ale dobre przyzwyczajenia trzeba kształtować od młodości :D
  • #6
    krzycho123
    Level 31  
    Dziękuje bardzo za odpowiedzi :) Wiem że Atmega to też AVR. Tylko jakoś zagmatwałem tak wyszło w poście . Wybiore chyba jednak Atmege 8 , potem moge stosować w swych projektach wyższe ATMEGI , język BASCOM bo nie chce się "zrazić do procków " na początku ;) .A po za tym nauke uP traktuje jako tylko domowe hobby.Nie zamierzamj w przyszłości pracować z elektroniką a już tym bardziej z mikroprocami . Pozdrawiam
  • Helpful post
    #7
    lukasb9
    Level 28  
    Andrzej_17 - kolega chyba nie wie co to takiego wstawka asemblerowa, bo jak dlamnie to w niektórych przypadkach jest ona błogosławieństwem, pisze programyw językach wysokiego poziomu, ale to nie znaczy że asembler jest do niczego, asembler jest "piękny" przez swoją prostote, tam wszystko widać co sie dzieje w procku, jaki rejest jest wykorzystany, co jest na stosie itd, itp... tak więc uczcie sie również asemblera,on nie wychodzi z uzycia!

    pozdrawiam łukasz
  • #8
    krzycho123
    Level 31  
    tak po przemyśleniu , to chyba jednak najpierw zaczne od płytki uniwersalnej , kilku switchy , LEdów i proca . Potem moge to wykorzystać na fabrycznym PCB.
  • Helpful post
    #9
    LordBlick
    VIP Meritorious for electroda.pl
    Andrzej_17 wrote:
    Quote:
    W czym programować najlepiej w asemblerze, jeżeli masz zamiar robić w przyszłości poważne projekty!


    To chyba jakieś żarty :D
    Kto poważny dzisiaj poważne projekty pisze w asemblerze?
    Kto się w takim olbrzymim kodzie połapie?
    Kto po przerwie będzie wiedział "co robił ten fragmencik kodu"?
    Kto w prosty sposób przeprowadzi obliczenia zmiennoprzecinkowe w asemblerze? (to tylko przykład)...
    Ja wiem kto, nie powiem... :P
    Jak ktoś nie umie porządnie i czytelnie pisać kodu ("a jakoś tam bedzie"), to nawet w Logo się pogubi ;) A "time to market" to na dobranoc grzecznym dzieciom w USA... ;) Jak spartolisz na szybkiego kod to i tak więcej czasu poświęcisz na poprawki, niż by go w asm raz porządnie napisał. Do pisania w asemblerze trzeba ogromnej wyobraźni i cierpliwości, aby pisać efektywnie. Kto nie posiada takowych umiejętności wykształconych dostatecznie i nie chce ich doskonalić, zdecydowanie odradzam, niech bawi się prefabrykatami w Bascom. ;)
  • Helpful post
    #10
    Andrzej_17
    Level 13  
    Quote:
    Jak ktoś nie umie porządnie i czytelnie pisać kodu ("a jakoś tam bedzie"), to nawet w Logo się pogubi A "time to market" to na dobranoc grzecznym dzieciom w USA... Jak spartolisz na szybkiego kod to i tak więcej czasu poświęcisz na poprawki, niż by go w asm raz porządnie napisał. Do pisania w asemblerze trzeba ogromnej wyobraźni i cierpliwości, aby pisać efektywnie. Kto nie posiada takowych umiejętności wykształconych dostatecznie i nie chce ich doskonalić, zdecydowanie odradzam, niech bawi się prefabrykatami w Bascom.


    Kolega widzę zwolennik benedyktyńskiej pracy...
    A propos "time-to-market": może właśnie z powodu takiego podejścia polski przemysł elektroniczy jest tam gdzie jest?
    Wiem, wychodzi na to że nieuki używają języków wysokiego poziomu, a magicy i geniusze asemblera... No proszę wybaczyć, ale się nie zgodzę...
    Główne zalety języków wysokiego poziomu (takiego jak C) to przede wszystkim:
    - przejrzystość kodu,
    - łatwość wprowadzania modyfikacji,
    - łatwość przenoszenia kodu na inny procesor (:!:)
    - szybkość pisania i dużo większa wydajność programisty
    - DUŻO mniejsze prawdopodobieństwo pomyłki
    - i jeszcze kilka innych

    Co do "wstawek asemblerowych": mimo że w swojej karierze zrobiłem kilka projektów w C, nie byłem zmuszony korzystać ze wstawek... Może to kwestia doświadczenia w programowaniu w C?

    pozdrawiam
  • Helpful post
    #11
    Jacu$
    Level 27  
    Quote:
    Jak ktoś nie umie porządnie i czytelnie pisać kodu ("a jakoś tam bedzie"), to nawet w Logo się pogubi :wink: A "time to market" to na dobranoc grzecznym dzieciom w USA... :wink: Jak spartolisz na szybkiego kod to i tak więcej czasu poświęcisz na poprawki, niż by go w asm raz porządnie napisał. Do pisania w asemblerze trzeba ogromnej wyobraźni i cierpliwości, aby pisać efektywnie. Kto nie posiada takowych umiejętności wykształconych dostatecznie i nie chce ich doskonalić, zdecydowanie odradzam, niech bawi się prefabrykatami w Bascom. :wink:


    Amen.
  • Helpful post
    #12
    LordBlick
    VIP Meritorious for electroda.pl
    Szanowny kolego, ja rozumiem Twoje powody do language-war, ale:
    1. Producent układów AVR (Atmel) daje darmowe narzędzia do asm i to ciągle ulepszane, czyli widzi sens, bo monitoruje ilość pobrań, ale to tak poza konkursem, nie mam zamiaru nikogo namawiać, skoro nie zrobił od dłuższego czasu (być może w ogóle) w asm ani jednego projektu i z braku wprawy wydaje mu się to nie do przeskoczenia (żadna tam benedyktyńska robota - jak często piszesz to masz już swoje procedury, które wklejasz, co nieco czasem zmieniając lub nawet stosując #include - tak, tak, współcześnie rozwijane asemblery są przyjazne dla programisty)... ;)
    2. Nie mam nastroju na wykazywanie wyższości jednych świąt na drugimi, zostańmy po prostu przy swoich zdaniach i róbmy to co potrafimy najlepiej... ;)
    3. Nikogo nie nazwałem nieukiem, każdy człowiek ma indywidualne zdolności i umiejętności.
    4. To nie ta platforma sprzętowa. Rozmawiamy w dziale "Mikrokontrolery", a tu liczą się w masowej produkcji jak najwydajniejsze (szybkie) oraz zajmujące jak najmniej pamięci programy, bo można użyć tańszy układ, a jeszcze żaden kompilator wyższego poziomu nie przeskoczył ręcznej optymalizacji kodu na µC - zbyt mała przestrzeń platformy sprzętowej... Program pisze się raz, programując wiele układów, więc TTM można sobie odpuścić na rzecz wydajności i małej objętości kodu wynikowego, niech ten programista posiedzi ten tydzień dłużej, ale produkcja niech będzie tańsza (produkt być może również ;))...
    5. Zawsze jest wiele dróg do rozwiązania problemów, i wybór ich zależy nie tylko od wydajności programisty, ale i całego zaplecza produkcyjno-inwestycyjnego, nad produkcją większej ilości urządzeń pracują zespoły, w których programiści szczególnie się nie wyróżniają jako tytani pracy.
    P.S. Jeśli upatrujesz przyczyn stanu polskiego przemysłu elektronicznego w "dłubaniu w asm" to gratuluję logiki - proponuję się przyjrzeć innym sektorom przemysłowym... Ja osobiście uważam, że politykami powinni był ludzie zajmujący się tym dożywotnio - jak już się nachapie, to mu wystarczy i może zacznie myśleć o innych, a jak nie - to koniec kariery. Wtedy u władzy pozostawaliby tylko ludzie odpowiedzialni. Taka trochę zmieniona monarchia. Życzę dobrej nocy... ;)
    --
    Pozdrawiam, Daniel
  • Helpful post
    #13
    Dexter77
    Level 28  
    Szanowny kolego Andrzej_17 (te 17 to pewnie wiek ??)
    Widac ze jestes jeszcze mlody i brakuje Ci doswiadczenia (to bez zadnych zlosliwosci) zapewne Twoje projekty nie sa zbyt zaawansowane skor nigdy nie musiales siegnac po asembler. Asembler musi znac kazdy doswiadczony programista. Sprobuj napisac program czasu rzeczywistego z kilkoma zrodlami przerwan, bez asemblera Twoj program przy byle okazji sie wykrzaczy bo np. stos sie przepelnil. Nie ujmujac zalet C ktore wymieniles wczesniej asembler w niektorych programach jest koniecznscia. nie zawsze oplaca sie kupic uklad 5 razy drozszy ale dwa razy szybszy w zwiazku z tym program napisany w C bedzie smigal jak nalezy. Mozna wlasnie przysiasc 30 min. dluzej i zrobic wstawke w asm. Dzieki nowoczesnym narzedziom jak makroasemblery mozna to robic bardzo szybko i niekiedy bardziej czytelnie niz w C !!
    Pozdro
    Dexter
  • Helpful post
    #14
    Andrzej_17
    Level 13  
    Nie wiem czy jest sens ciągnąć dalej tą dyskuję. Widzę, że tu zatwiardziali zwolennicy aseblera tylko mają prawo się wypowiedzieć.
    Co do mojego nicku i wieku: łatwo jest osądzać ludzi kiedy się nie wie z kim się ma do czynienia, prawda?

    Osobiście mnie śmieszą teksty typu: "program od razu się wykrzaczy" sugerują tylko jedno: taka osoba chyba w życiu nie używała np. C.
    Osobiście nie mam nic przeciwko asemblerowi. Jeśli ktoś chce się męczyć proszę bardzo! Tylko wmawianie początkującemu, że jedyny "słuszny" język to asembler zakrawa na żart.
    W ilu firmach dzisiaj pisze się w asemblerze? Kogo na to stać?
    Jak często w czasopismach i artykułach tam publikowanych (nie tylko polskojęzycznych) przedstawia się programy pisane w asemblerze?
    W asemblerze to można sobie napisać program klikunasto- klikudziesięcio liniowy. Optymalizacja kodu? Zgodzę się, czasem są krytyczne "czasówki", kiedy programista chce coś zrobić z dokładnością do jednego taktu. Optymalizacja objętości? Dzisiaj coraz bardziej traci na znaczeniu - jesteśmy już zupełnie w innym miejscu niż wtedy gdy królował 8051 czy 89c2051, teraz po prostu pamięć jest tania...

    To tyle tym razem
  • Helpful post
    #15
    LordBlick
    VIP Meritorious for electroda.pl
    Andrzej_17 wrote:
    Nie wiem czy jest sens ciągnąć dalej tą dyskuję. Widzę, że tu zatwiardziali zwolennicy aseblera tylko mają prawo się wypowiedzieć.
    Co nie przeszkodziło zatwardziałemu zwolennikowi C obstawać przy swoim i wielokrotnie wyrazić własne zdanie. Nie jesteśmy przeciwko, a wręcz popieramy.
    Andrzej_17 wrote:
    Osobiście nie mam nic przeciwko asemblerowi. Jeśli ktoś chce się męczyć proszę bardzo!
    Bardzo dziękuję za wyrazy współczucia... Tym niemniej czuję się świetnie ;)
    Andrzej_17 wrote:
    Tylko wmawianie początkującemu, że jedyny "słuszny" język to asembler zakrawa na żart.
    Zależy od podejścia. Czy znajomość architektury procesora, działania i listy jego rozkazów jest czymś gorszącym ? Myslę, że się przyda jak najbardziej początkującemu, który, nawet, jak się zdecyduje później na C, będzie wiedzieć dokładnie co wyprawia kompilator, a może nawet napisać własny ;) Nie ma jedynego słusznego języka, najlepiej znać wszystkie, aby wybierać, mając o wyborach praktyczne, nie tylko teoretyczne pojęcie...
    Andrzej_17 wrote:
    W ilu firmach dzisiaj pisze się w asemblerze? Kogo na to stać?
    Oj, kolega mało świata zwiedził, właśnie w tych, co zarabiają najwięcej...
    Andrzej_17 wrote:
    Jak często w czasopismach i artykułach tam publikowanych (nie tylko polskojęzycznych) przedstawia się programy pisane w asemblerze?
    No cóż, czasopisma, w których są jakieś listingi programów są tworzone z myślą o początkujących, lubiących polutować, wklepać kilka linijek kodu, bo doświadczony programista z różnych względów (np. prawa autorskie) tworzy aplikacje samodzielnie. No i listing w asm zajmie sporo miejsca, które można przecież poświęcić na reklamy... ;)
    Andrzej_17 wrote:
    W asemblerze to można sobie napisać program klikunasto- klikudziesięcio liniowy.
    Owszem, nawet 2000-3000 linii kodu, zwłaszcza, że jedna linijka w asm to z reguły maksymalnie kilkanaście znaków i Enter... Dla wprawnego programisty, korzystającego z odpowiednich narzedzi (kolorowanie składni, podpowiedzi z listy rozkazów itp.), góra 3 sekundy.
    Andrzej_17 wrote:
    Optymalizacja objętości? Dzisiaj coraz bardziej traci na znaczeniu - jesteśmy już zupełnie w innym miejscu niż wtedy gdy królował 8051 czy 89c2051, teraz po prostu pamięć jest tania...
    No tak, wydać 1,5PLN na AT90S2313-4, a 4-7PLN na ATmega8-16 i to razy np. 2000 sztuk to niewielka różnica... ;)
    --
    Pozdrawiam, Daniel
  • Helpful post
    #16
    Dexter77
    Level 28  
    W cale nie jestem zagorzalym zwolennikiem asm, nie jestem tez zwolennikiem C. Dla scislosci uzywam obydwoch. Programowaniem zajmuje sie od kilkunastu lat (oj bedzie juz ze 12, zawodowo 5) i wiem poprostu z doswiadczenia w pracy ze dopiero polaczenie zalet obydwoch srodowisk daje zadowalajace rezultaty na polu aplikacji "profesjonalnych" uzywanych w produkcji masowej. Tak jak napisal Light'i 2 zl na tysiacach sztuk w porownaniu z 30 min programisty to jest ogromny zysk. W sam raz na kilka moich pensji.
    Asembler trzeba znac tez z innego powodu nawet jesli uzywasz tylko i wylacznie C. Napisal juz o tym Light'i. Nigdy nie wiadomo co wymysli kompilator. Stracilem kiedys 2 godziny na szukanie bledu w programie, dopiero olsnilo mnie zeby zajrzec co wyprawia kompilator. Po zajrzeniu do listingu w ciagu 5 sek. juz wiedzialem ze problem nie tkwi w kodzie programu tylko w skladni ktora nie byla zgodna ze standardem ANSI C i kompilator kompilowal nie zglaszajac bledu ale program zle dzialal. Dlatego po przeczytaniu Twoich postow co nieco sie we mnie wzburzylo i zapragnalem wziasc udzial w tej bezsensownej dyskusji. Bezsensownej bo Twoje argumenty do mnie jako doswiadczonego programisty nie trafiaja, a zapewne moje do Ciebie jako programisty ktory nie musial stawac przed takimi wyborami jakimi ja musialem sie kierowac.
    Pozdro
    Dexter
  • Helpful post
    #17
    Andrzej_17
    Level 13  
    Gwoli uściślenia: nie pisałem, że nie należy poznać choćby podstaw asemblera, a wręcz przeciwnie, jak najbardziej!
    To samo się tyczy architektury. Znam osoby, które próbują coś napisać nie przeczytawszy noty katalogowej:!:
    Problem faktycznie występuje wtedy, gdy programista nie zna środowiska dostatecznie dobrze, ogromna większość przypadków, gdy program działa nieprawidłowo jest spowodowana bądź to nieznajomością kompilatora i języka, badź błędem logiczym programu.

    Włączyłem się do tej dyskusji w zasadzie z powodu stwierdzenia jednego z kolegów, że "poważne programy to tylko w asemblerze"...
    I takie coś pisze się do początkującego! Ja to sobie nieco inaczej wyobrażam: najpierw kurs architektury i małe wprowadzenie do asemblera, a następnie przesiadka na język wyższego poziomu.
    I właśnie najbardziej się to tyczy większych projektów!

    Amen. Już wystarczy.
  • Helpful post
    #18
    PROGRAMISTA
    Level 12  
    Oj kolego przekręcasz moje słowa napisałem najlepiej a nie "tylko" a to już chyba dużo zmienia
  • Helpful post
    #19
    LordBlick
    VIP Meritorious for electroda.pl
    Andrzej_17 wrote:
    Ja to sobie nieco inaczej wyobrażam: najpierw kurs architektury i małe wprowadzenie do asemblera, a następnie przesiadka na język wyższego poziomu.
    Brzmi to bardzo patetycznie, tym niemniej nie ma co się na asm obrażać, kompilacja niektórych wyrażeń standardowych (pętle, warunki itp) mnie osobiście zachęca do zrobienia wstawki w asm, która załatwi to w kilka linijek... Np. po co porównywać całą liczbę typu int, gdy jesteśmy pewni, że wystarczy jej młodszy bajt ? Tak przy okazji, bo widzę że mam z fachowcem do czynienia - mam problem, jak w avrgcc wyłuskać bajt z wyrażenia zdefiniowanego za pomocą :
    #define usDiv		1000000	// microsecond divisor
    #define msDiv		1000	// milisecond divisor
    #define T0TickDiv	usDiv // usDiv or msDiv
    #define T0Scale		64
    #define T0Tick		40
    #define T0cnt	(0xFF-((T0Tick*F_CPU)/(T0TickDiv*T0Scale))) ; <--- O to wyrażenie mi się rozchodzi.
    :?:
    W AVRasm2 mam to bez problemu za pomocą low(T0cnt), a tu kombinowałem za pomocą TCNT0=(unsigned char)T0cnt; i nic, kompilator wyrzuca :
    test.c:36: warning: integer overflow in expression
    i oczywiście uzyskana wartość jest błędna.
    Andrzej_17 wrote:
    Amen. Już wystarczy.
    No nie badźmy takie, jak ma ktoś coś ważnego do powiedzenia, niech dopisze... ;)
  • Helpful post
    #20
    Andrzej_17
    Level 13  
    Jeśli przyjąc, że T1cnt jest typu int, to bardzo prosto:

    unsigned char lowb,highb;

    lowb=(unsigned char)T1cnt;
    highb=(unsigned char)T1cnt>>8;

    pozdr.
  • Helpful post
    #21
    LordBlick
    VIP Meritorious for electroda.pl
    Hmmm... Ale mi chodzi bez użycia zmiennych, dotychczas kompilator grzecznie mi kompiluje na
    ldi r16, <wartosc_hex>
    out TCNT0, r16
    tylko wartosc_hex jest nieprawidłowa...
    Poza tym przy proponowanej opcji(T0cntB=(unsigned char)T0cnt; [deklaracja wcześniej jest]) też występuje to samo ostrzeżenie(warning: integer overflow in expression), nawet kombinowałem z :
    #define usDiv      1000000   // microsecond divisor
    #define msDiv      1000   // milisecond divisor
    #define T0TickDiv   usDiv // usDiv or msDiv
    #define T0Scale      64
    #define T0Tick      40
    #define T0cnt   (0xFFFF-((T0Tick*F_CPU)/(T0TickDiv*T0Scale))) ; <--- O to wyrażenie mi się rozchodzi.
    i nie pomogło... To samo w AVRasm2 idzie jak burza... Taka pierdoła, a ja jestem całkiem zniechęcony do C dla mikrokontrolerów...
  • Helpful post
    #22
    Andrzej_17
    Level 13  
    No ale co to zmienia że ma być bez zmiennych?

    Przypisanie wtedy robimy bezpośrednio do TCNT0:

    TCNT0=(unsigned char)zmienna_int16>>8

    A przepełnienie może występować z zupełnie innego powodu.
    Jakiego kompilatora używasz?
    Ja przetestowałem to na najnowszym WinAVR i nie ma problemów

    pozdr
  • Helpful post
    #23
    LordBlick
    VIP Meritorious for electroda.pl
    WinAVR-20050214, czyli najnowsza wersja z http://sourceforge.net/projects/winavr/.
    Właśnie nie mogę dojść do powodu tego przepełnienia, jak typ danych przybierają domyślnie wartości z #define lub jak tym manipulować, gdy są wyrażenia matematyczne ? Trochę przekombinowałem, nie wkleiłem w całości ten kod, z którym mam problem, bo jest on w rzeczywistości porozrzucany po różnych plikach :
    #define Trise		0x07 // exz. ((1<<CS02)|(1<<CS01)|(1<<CS00))
    #define Tfall		0x06
    #define Tdiv1024	0x05 // prescaler dzielący częstotliwość  zegara
    #define Tdiv256		0x04 // systemowego (kwarcu lub wewnętrznego oscylatora RC)
    #define Tdiv64		0x03
    #define Tdiv8		0x02 
    #define Tdiv1		0x01
    #define Tstop		0x00
    #define usDiv		1000000	// microsecond divisor
    #define msDiv		1000	// milisecond divisor
    #define T0div		Tdiv256
    #define T0Tick		1
    #define T0TickDiv	msDiv // usDiv or msDiv
    #ifndef T0cnt
    	#if (T0div==Tdiv1024)
    		#define T0Scale	1024
    	#elif (T0div==Tdiv256)
    		#define T0Scale	256
    	#elif (T0div==Tdiv64)
    		#define T0Scale	64
    	#elif (T0div==Tdiv8)
    		#define T0Scale	8
    	#elif (T0div==Tdiv1)
    		#define T0Scale	1
    	#endif
    	#ifdef T0Scale
    		#define T0ovr1	(T0Tick*F_CPU)
    		#define T0ovr2	(T0TickDiv*T0Scale)
    		#define T0ovr	((T0ovr1/T0ovr2))
    		#define T0cnt	(0xFF-(T0ovr & 0xFF))
    	#endif
    #endif
    Gdzie tu się rąbnąłem ? Chcę mieć przerwanie co 1 ms związane z wartością dla TCNT0 wyliczaną przez kompilator z wartości zegara systemowego, zgodnie z założeniami zdefiniowanego w Makefile za pomocą F_CPU = 8000000. T0ovr wychodzi mi 8000000/256000=8000/256=31,25, jeśli ma być to &0xff to powinno zostać 31, a T0cnt powinno być 224 (0xE0) - nie ma przepełnienia dla unsigned char, bo skąd, czy się mylę ?
    No i drugie pytanie, jak wyświetlić wartości wyliczone z definicji podczes kompilacji (w okienku "Output" Programmers Notepada) ? #warring ?
  • Helpful post
    #24
    Andrzej_17
    Level 13  
    Nie będę już może wchodził w szczegóły, warto sobie zdać sprawę z jednego.
    Dyrektywy #define są poleceniami preprocesora, a nie kompilatora. Preprocesor po prostu wstawia wyrażenie po prawej strony #define w miejsce wyrażenia po lewej stronie, występującego w programie.
    Jeden przykład:

    #define M 2+3

    X= M*M;

    Jaka będzie wartość X po tej operacji?
    Ano nie będzie 25, jak ktoś by podejrzewał tylko:
    X=2+3*2+3 = 11

    Zaskoczenie? Nie, po prostu preprocesor przy obliczaniu X zrobił tylko bezmyślne wstawienie za M tego co było w dyrektywie #define.

    Dlatego można sobie wstawić do programu rozwinięcie, które znajduje się w linii #define i sprawdzić "na piechotę" co się dzieje.

    I jeszcze jedno. Często problemy z obliczeniami w dyrektywie #define wynikają z brania najmniejszej wymaganej objętości zmiennej występującej przy obliczeniu. Do rozszerzania zmiennych służą specjalne modyfikatory np. L dla long integer, UL, unsigned long integer, itp.
    Manual dotyczący preprocesora można znaleźć tutaj:
    http://gcc.gnu.org/onlinedocs/gcc-3.4.4/cpp/

    A tak na marginesie, osobiście wolę tego typu bardziej skomplikowane oblicznia umieścić w samym programie niż w dyrektywie #define

    pozdr
  • Helpful post
    #25
    LordBlick
    VIP Meritorious for electroda.pl
    Andrzej_17 wrote:
    Jeden przykład:

    #define M 2+3

    X= M*M;

    Jaka będzie wartość X po tej operacji?
    Ano nie będzie 25, jak ktoś by podejrzewał tylko:
    X=2+3*2+3 = 11

    Zaskoczenie? Nie, po prostu preprocesor przy obliczaniu X zrobił tylko bezmyślne wstawienie za M tego co było w dyrektywie #define.
    Dlatego zastosowałem nawiasy...
    Andrzej_17 wrote:
    Dlatego można sobie wstawić do programu rozwinięcie, które znajduje się w linii #define i sprawdzić "na piechotę" co się dzieje.

    I jeszcze jedno. Często problemy z obliczeniami w dyrektywie #define wynikają z brania najmniejszej wymaganej objętości zmiennej występującej przy obliczeniu. Do rozszerzania zmiennych służą specjalne modyfikatory np. L dla long integer, UL, unsigned long integer, itp.
    Manual dotyczący preprocesora można znaleźć tutaj:
    http://gcc.gnu.org/onlinedocs/gcc-3.4.4/cpp/
    OK, bardzo dziękuję, może z takim kompletem informacji dojdę do ładu ;)
    Andrzej_17 wrote:

    A tak na marginesie, osobiście wolę tego typu bardziej skomplikowane oblicznia umieścić w samym programie niż w dyrektywie #define
    A ja niestety nie, bo po co mi nadmiarowy kod, gdy ma być wstawiona ostatecznie "sucha" wartość do rejestru ? Zajęłoby to niepotrzebnie cykle w obsłudze przerwania i pamięć RAM na zmienne... Po co męczyć mikrokontroler, gdy co trzeba wyliczy o wiele szybszy procesor na PC i to tylko raz ? Spotkałem się z taką możliwością w podobno mniej przyjaznym asemblerze, chciałem i tutaj :(.
    --
    Pozdrawiam, Daniel
  • Helpful post
    #26
    Dexter77
    Level 28  
    Skoro byla mowa juz o wojnie to nasunelo mi sie takie skojarzenie. Programowanie to jak wojna. Typowa jednostka jest zolnierz uzbrojony w karabin ktory wiadomo szybko strzela i jest prosty w obsludze. Niestety zolnierze czesto strzelaja z nadmiarem majac nadzieje ze w cos trafia wobec tego potrzebne jest zaopatrzenie w duza ilosc zasobow czyli amunicji. Wszystko jest ladnie pieknie dopoki taki oddzial nie natrafi np. na bunkier. Mozna sprobowac wziasc go szturmem strzelajac z karabinow liczac sie z ogromnymi stratami lub nawet calkowita porazka, a mozna np. zaczekac 30min. i wezwac wsparcie w postaci czolgu. Czolg ze swoim precyzyjnym celownikiem laserowym, stabilizacja lufy oraz ogromnym kalibrem zalatwi sprawe w w mgnieniu oka. Tak sie wygrywa bitwy w trakcie wojny, na placu zabaw wystarczy karabin na wode ;)
    Light'i a GCC nie ma takiej funkcji jak low i high ?? Do tej pory w kazdym z jezykow wyzszego rzedu jakiego uzywalem zawsze byly do dyspozycji te funkcje.

    Pozdro
    Dexter
  • Helpful post
    #27
    LordBlick
    VIP Meritorious for electroda.pl
    C:\Devel\elektro\AVR-gcc\keytest/test.c:38: undefined reference to `low'
    Linia 38 :
    	TCNT0=low(T0div);
    - czyli tylko, jeśli jest to zaszyte w jakiejś bibliotece, bo spotkałem się tylko z odmianą lo8() i hi8(), ale w asemblerze od avr-gcc, w projekcie minidds.
    Tym niemniej, tak jak Andrzej_17 poradził - zadziałało z dopisaniem do wszystkich definicji liczb bioracych udział w obliczeniach "UL" - i oto fragment pliku test.lss:
    void InitOvrTimer0(void)
    	{
    	TCCR0=(unsigned char)T0cnt;
      72:	80 ee       	ldi	r24, 0xE0	; 224 <-- takiej wartości się tu spodziewałem... ;)
      74:	83 bf       	out	0x33, r24	; 51
    
    Dziękuję bardzo za podpowiedź.
    Co do sposobu kontrolowania wyliczonych wartości w trakcie kompilacji w oknie "Output" to jeszcze się nie dogrzebałem, bawił się tym ktoś ?
    --
    Pozdrawiam, Daniel
  • Helpful post
    #28
    aster11
    Level 19  
    Obserwując tak ożywioną dyskusję, wtrącę swoje kilka zdań. Tylko nie krytykujcie zaraz każdego mojego słowa i nie wyzywajcie od żółtodziobów (bo faktycznie na polu programowania mikrokontrolerów jestem jeszcze żółtodzibem :D).

    Jednakże w kwestii używania asm i C w programowaniu mikrokontrolerów mam pewne poglądy. Jesli chodzi o przedmówców, to popieram wiele argumantów Andrzeja_17, a najbardziej zgadzam się ze stanowiskiem Dextera77.

    Aby sprawnie programować (w obecnych czasach) mikrokontrolery, najlepiej jest łączyć zalety języka bezpośredniego - asm i języka wyższego poziomu - np. C. Ewolucja działa jednak na korzyść języków wyższego poziomu.
    Można to porównać z ewolucją programowania komputerów. W prehistorii używano do tego prawie wyłącznie kodu maszynowego. Potem powstały rozliczne języki wyższego poziomu. "Poziom" języków coraz bardziej wzrastał - np. programowanie obiektowe. Obecnie w większości typowych aplikacji zaleca się i stosuje języki wysokiego poziomu, a zabawę kodem niższego poziomu (nawet już nie asemblerowym), tam gdzie nie ma takiej potrzeby, uważa się za naganne i nieefektywne (w sensie inżynierii oprogramowania). Oczywiście istnieją takie dziedziny (zwłaszcza związane z odwołaniami do sprzętu), gdzie użycie asm jest nadal wskazane lub może nawet konieczne.

    Taka ewolucja w dziedzinie komputerów możliwa była głównie dzięki rozwojowi sprzętu. Podobną ewolucję przechodzi teraz arena mikrokontrolerów, pamięć tanieje, niektóre urządzenia są wprost optymalizowane pod kątem użycia języka wysokiego poziomu (np. wspominane AVR). Wydaje mi się, że już teraz w nowoczesnych mikrokontrolerach szala przechylona jest na stronę języków wyższego poziomu. Gdybym miał wymienić zalety obu sposobów programowania, zrobiłbym to tak:

    1. Język wyższego poziomu (np. C):
    a) duża wygoda i przejrzystość programowania, mniejsze prawdopodobieństwo błędu, duża czytelność i modyfikowalność (dobrze napisanego) kodu ... i inne zalety, znane np. z użycia takich języków w programowaniu komputerów.
    /Tu niektórzy twierdzą, że mają prawie to samo w makroasemblerach. Moim zdaniem jest to wtedy użycie asmeblera stylizowane na wzór języka wyższego poziomu i jawne użycie takiego języka zwiększy w takim przypadku tylko wygodę programowania, niewiele ujmując jego skuteczności - chociaż różne są przyzwyczajenia i nie potępiam tych, którzy lubią widzieć cały czas jak na dłoni operacje na każdym rejestrze układu; nie zgodzę się jednak z tym, że tylko takie podejście zasługuje najbardziej na miano "profesjonalizmu"./
    b) dobry dostęp do pokładów sprzętowych - w dobrych kompilatorach języków wyższego poziomu, dedykowanych dla mikrokontrolerów, dostęp do sprzętu jest tak zorganizowany, że nie potrzeba (nie ma konieczności) odwoływania się do asm (pomijam tu procedury czasu krytycznego).

    2. Asembler:
    a) większa zwartość kodu wynikowego:
    Jest to niepodważalna zaleta asm, ale coraz mniej istotna obecnie, tak jak przed kilku(nastu) laty straciła krytyczne znaczenie w programowaniu komputerów. Pisałem kiedyś podobny program najpierw w asm, potem w C. W asm zaoszczędziłem ok. 25% pamięci. Uważam się za kiepskiego programistę asm, ale myślę, że nawet ekspert nie ścisnąłby programu na więcej jak 50%. A różnice cen dla podwójnej ilości pamięci to dziś wiadomo ... Czasem nawet nowsze mikrokontrolery z większą pamięcią i lepszym wyposarzeniem są promowane po niższych cenach, niż starsze odmiany. Już zupełnie nie ma to większego znaczenia, gdy mikrokontroler jest częścią dużego urządzenia i stanowi ułamek procenta jego ceny.
    Jest to jednak zaleta asm, i czasem /zgadzam się/ należy ją wykorzystać - np. gdy cena mikrokontrolera jest podstawą ceny urządzenia i rzeczywiście - z ilością wykorzystanej pamięci cena ta rośnie - na pewno opłaca się przysiąść trochę nad programem, żeby zarobić potem na setkach/tysiącach/milionach sprzedawanych urządzeń.
    b) procedury czasu krytycznego:
    Zawsze będą fragmenty programu, które należy zrealizować najszybciej jak sie da, niezależnie od prędkości działania układu. Dowodem może być fakt, że procedury takie występują nadal we współczesnych szybkich komputerach. Tutaj bezpośrednie użycie asm w postaci wstawek lub procedur będzie chyba zawsze niezastąpione!

    Mama nadzieję, że nikogo nie uraziłem:).
    Pozdrawiam wszystkich.
  • Helpful post
    #29
    LordBlick
    VIP Meritorious for electroda.pl
    Jeszcze o jednym, miano "profesjonalizmu" uważam za niezależne od języka programowania. Profesjonalista, to ten kto sprawnie i bezbłędnie wykona powierzone zadanie, a jak to zrobi to juz nikogo nie powinno obchodzić, powinien tylko potrafić spełnić założenia projektowe. Róbmy to, co nam najlepiej wychodzi, nie odżegnując się od znajomości innych możliwości.
    --
    Pozdrawiam, Daniel