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

WinAVR toolchain, makefile, programator i symulacja w Atmel Studio 7 [Poradnik]

29 Kwi 2018 18:25 1140 11
  • Poziom 24  
    Witam wszystkich forumowiczy zainteresowanych tematem 8-bitowych mikrokontrolerów AVR w moim poradniku!!

    Na wstępie parę słów na temat przyczyny oraz celu, jaki skłoniła mnie do napisania poradnika. (Niezainteresowanych proszę o przejście od razu do sekcji "Zaczynajmy".) Przyczyna jest dość prosta, zwyczajnie miałem potrzebę zaimportowania swoich projektów do nowego środowiska. Oczywiście można skorzystać z eclipse, jednak problem jest z symulatorem. Wprawdzie znalazłem poradnik jak podpiąć debugger sprzętowy oraz simulavr do eclipse, jednak przydatność samego symulatora z pakiety WinAVR jest prawie zerowa. Miałem dłuższą przerwę w kontakcie z uC, a swoje projekty tworzyłem głownie przy użyciu toolchain WinAVR. Korzystałem też z symulatora w AVR Studio 4, który w tamtych czasach bardzo mi się podobał. Jakiś czas temu pojawił się potrzeba szybkiego napisania programu do chińskiego urządzane celem poprawienia jego funkcjonalności, aby nie tracić czasu na adaptacje i przenoszenie moich bibliotek do nowego środowiska postanowiłem wykorzystać to, co dobrze znam. Oczywiście klepanie programów w Programmers Notepad nie jest zbyt wygodne, zwłaszcza w porównaniu z tym, co oferują współczesne platformy. Nie jestem zwolennikiem posiadania kilku środowisk i przeskakiwaniu między nimi, a symulator może być bardzo przydatny, dlatego postanowiłem znaleźć sposób na przeniesienie projektów bezpośrednio do najnowszego Atmel Studio. Mogą się tutaj pojawić opinie, że łatwiej było by przenieść sam kod do nowego projektów. Niestety nie jest to takie proste, pomijając nawet kłopoty przy ponownej kompilacji. Jeszcze większe schody pojawiają się, gdy korzysta się z rozbudowanego pliku makefile, gdzie w zależności od jednego z parametrów, dokonuje się kompilacji warunkowej aby wygenerować wsad dla odpowiedniego urządzenia. Więcej na ten temat poniżej.

    Toolchain WinAVR i makefile

    Jak powszechnie wiadomo w pliku makefile znajdują się instrukcje dla programu meke decydujące o sposobie i przebiegu kompilacji. W platformach jak Atmel Studio generowany jest on automatycznie, a jego struktura wynika z konfiguracji jakiej dokonujemy podczas tworzenia nowego projektu. Natomiast w toolchain WinAVR mamy program o nazwie MFile, który pozwala nam na generowanie takiego pliku, gdzie możemy go później dowolnie modyfikować.
    WinAVR toolchain, makefile, programator i symulacja w Atmel Studio 7 [Poradnik]

    Za pomocą odpowiednie opcji wybieramy nazwę pliku z programem, typ uC, częstotliwość taktowania, rodzaju programatora itd. Tak wygenerowany plik dołączamy do katalogu z naszym projektem. Jego zwartość może wydawać się dość skomplikowana, zwłaszcza dla początkujących, jednak nie będę się tutaj rozwodził nad samą składnią. Takie rozwiązanie pozwala na duża elastyczność, co wykorzystamy do podpięcia dowolnego programatora w Atmel Studio. Poniższy fragment kodu z wygenerowanego pliku makefile definiuje typ programatora oraz ścieżkę do plików .hex z zawartością flash i eeprom.
    Kod: makefile
    Zaloguj się, aby zobaczyć kod
    Uzupełniając go o dwie linijki przedstawione poniżej, możemy za jednym zamachem przy wgrywaniu programu, zaprogramować również fuse-bits oraz lock-bits.
    Kod: makefile
    Zaloguj się, aby zobaczyć kod
    Po jednorazowym wyliczeniu, nie potrzebujemy dodatkowego narzędzia, zapisujemy ich wartość każdorazowo i mamy pewność, że po zaprogramowaniu nawet nowego uC zawsze są poprawnie ustawione.

    Elastyczność składni pliku makefile pozwala dodatkowo na kompilacje warunkową, o czym wspominałem we wstępie. Możemy w ten sposób za pomocą jednego parametru, zdecydować z jaką wersją urządzenia mamy do czynienia i wygenerować odpowiednie wsady.
    Kod: makefile
    Zaloguj się, aby zobaczyć kod
    Dodatkowo w pliku makefile mamy możliwość podpięcia skryptów, które przykładowo mogą generować licznik kompilacji. Taki licznik można przekazać do programu, czy nawet dołączyć do wersji programu i zapisać w pamięci eeprom. Jeśli będzie ktoś zainteresowany, to mogę załączyć przykłady takich skrypt oraz opisać sposób na automatyczne generowanie daty/czasu kompilacji programu i zapis tych informacji do pamięci flash/eeprom. Jeśli nie wykorzystujemy całej zawartości pamięci flash/eeprom, to możemy wrzucić tam te dane. Zapisanie nr kompilacji może być przydatne w przypadku identyfikacji wersji oprogramowania wgranego do urządzenia.

    Samo wywołanie programu make z odpowiednimi parametrami odbywa się w środowisku w jakim tworzymy kod. Domyślnie dla toolchain WinAVR jest to odpowiednio skonfigurowany Programmers Notepad. W zakładce Tool mamy trzy komendy.
    WinAVR toolchain, makefile, programator i symulacja w Atmel Studio 7 [Poradnik]

    Jest to: Make All - służąca do skompilowania projektu, Make Clean - przeznaczona do czyszczenia projektu oraz Make Program - do programowania. Odpowiednio przygotowany plik makefile sprawia, że te trzy komendy wystarczają w zupełności do zaprogramowania mikrokontrolera . Cała konfiguracja zawiera się w tym pliku, a przykładowa zmiana programatora sprowadza się do edycji dwóch linii kodu. Przeniesienie tak przygotowanego projektu nie jest takie proste, dlatego powstał ten poradnik! Po "wstępnych" wyjaśnieniach możemy w końcu przejść do meritum! :D

    Zaczynajmy - Konfiguracja Atmel Studio 7.0

    Zakładam, że mamy projekt przygotowany w języku C za pomocą toolchain WinAVR wraz z plikiem makefile i chcemy go przenieść bezboleśnie do Atmel Studio 7.0, tak aby móc uruchomić symulacje, czy skorzystać z dowolnego programatora wspieranego przez AVRDUDE. W moim przykładzie mamy do czynienia z ATmega32A, projekt nazywa się led_blink, a kod źródłowy znajduje się w pliku o nazwie led_blink.c (w wielu przypadkach będzie to domyślny main.c). Jest to swoisty "hello world" w postaci mijającej LED. Korzystam z systemy Windows 10, Atmel Studio 7.0.1645 oraz WinAVR 20100110.

    1. Podpięcie toolchain WinAVR pod Atmel Studio

    W pieszej kolejność musimy dodać naszego toolchain-a, więc wybieramy Tools->Options..., gdzie przechodzimy do opcji Toolchain->Package Configuration [1]. W polu Toolchains: wybieramy Atmel AVR 8-bit (C language) [2] i klikamy Add Flavour [3].
    WinAVR toolchain, makefile, programator i symulacja w Atmel Studio 7 [Poradnik]

    W oknie, które się pojawi, w polu Package Name [4] wpisujemy (dowolną) nazwę. Natomiast w polu Package Base Path [5] podajemy ścieżkę do plików bin dla WinAVR, w moim przypadku jest to C:\WinAVR\bin. Klikamy Add [6], a następnie OK [7]. Pierwszy etap mamy z głowy.
    WinAVR toolchain, makefile, programator i symulacja w Atmel Studio 7 [Poradnik]

    2. Tworzenie nowego projektu

    Aby stworzyć nowy projekt wybieramy File->New->Project..., a następnie jak na rysunku poniżej, wybieramy nowy projekt GCC dla języka C ([1] i [2]). Nadajemy odpowiednią nazwę w polu [3], w tym przykładzie jest to led_blink. Jeśli nie tworzymy projektu składającego się z kilku podprojektów, lub nie do końca wiemy do czego służy ta opcja, to zalecam odznaczyć Create directory for solution [4]. Na koniec klikamy OK.
    WinAVR toolchain, makefile, programator i symulacja w Atmel Studio 7 [Poradnik]

    W okienku Device Selection wybieramy uC z jakiego korzystamy, musi on być taki sam jak w pliku makefile! Polecam skorzystać z pola do wyszukiwania [5], a następnie wybrać odpowiedni model z listy [6], po czym klikamy OK.
    WinAVR toolchain, makefile, programator i symulacja w Atmel Studio 7 [Poradnik]

    Po utworzeniu nowego projektu powinniśmy mieć widok jak poniżej.
    WinAVR toolchain, makefile, programator i symulacja w Atmel Studio 7 [Poradnik]

    Jeśli nasz plik z kodem źródłowym nosi inną nazwę niż main.c, to musimy ją zmienić również tutaj, gdyż w innym przypadku symulacja nie zadziała. W tym celu klikamy prawym klawiszem na plik main.c, wybieramy Rename i zmieniamy nazwę na odpowiednią, w tym przykładzie jest to led_blink.c. Na koniec zapisujemy wszystko WinAVR toolchain, makefile, programator i symulacja w Atmel Studio 7 [Poradnik] i zamykamy Atmel Studio.

    3. Podmiana plików

    Następnym krokiem jest podmiana plików utworzonych przez Atmel Studio na nasz projekt stworzony w WinAVR. Domyślnie Atmel Studio wrzuca projekty do katalogu C:\Users\<users_name>\Documents\Atmel Studio\7.0\<nazwa_projektu>, gdzie należy skopiować całą zawartość projektu z WinAVR nadpisując plik z kodem źródłowym programu.

    4. Konfiguracja projektu

    Po wykonaniu zabiegu opisanego w pkt 3 przechodzimy do konfiguracji projektu w Atmel Studio. W tym celu klikamy prawym na projekt i wybieramy Properties.
    WinAVR toolchain, makefile, programator i symulacja w Atmel Studio 7 [Poradnik]

    W zakładce Build [1], w polu Configuration: wybieramy profil Debug [2], zaznaczamy pole Use External Makefile[4], klikamy Browse [4] i wskazujemy właściwy plik makefile.
    WinAVR toolchain, makefile, programator i symulacja w Atmel Studio 7 [Poradnik]

    Zmieniamy profil na Release [5] i postępujemy analogicznie jak w przypadku profilu Debug.
    WinAVR toolchain, makefile, programator i symulacja w Atmel Studio 7 [Poradnik]

    W kolejnym kroku przechodzimy do zakładki Build Events [6], w polu Configuration: wybieramy profil Release, po czym w polu tekstowym Post-build event command line: wpisujemy komendę "make.exe" program [8]. Wpisana komenda spowoduje, że po wykonaniu polecenia Build, gdy aktywny jest profil Release automatycznie zostanie zaprogramowany nasz uC. Odpowiada to sekwencji poleceń Make All oraz Make Program wywołanej w Programmers Notepad. Jeśli aktywny będzie profil Debag, to Atmel Studio wygeneruje wyłącznie pliki .hex, bez programowania uC. Sama konfiguracja programatora znajduje się w pliku makefile, co zostało opisane w rozdziale "Toolchain WinAVR i makefile", może to być dowolny programator współpracujący z AVRDUDE.
    WinAVR toolchain, makefile, programator i symulacja w Atmel Studio 7 [Poradnik]

    Następnie przechodzimy do zakładki Tool [9], gdzie w sekcji Selected debugger/programmer wybieramy Simulator [10]
    WinAVR toolchain, makefile, programator i symulacja w Atmel Studio 7 [Poradnik]

    Zostaje nam ostatnia zakładka Advanced [11], gdzie w polu Toolchain Flavour: wybieramy skonfigurowany w pkt 1 toolchain. W naszym przykładzie nosi on nazwę WinAVR [12]
    WinAVR toolchain, makefile, programator i symulacja w Atmel Studio 7 [Poradnik]

    Na koniec zapisujemy wszystkie zmian WinAVR toolchain, makefile, programator i symulacja w Atmel Studio 7 [Poradnik] i GOTOWE!

    5. Uruchomienie symulatora

    Aby uruchomić symulator przechodzimy do karty z kodem programy, w naszym przypadku led_blink.c, wybieramy profil Debug, po czym klikamy na ikonę Start Debugging and Break.
    WinAVR toolchain, makefile, programator i symulacja w Atmel Studio 7 [Poradnik]

    Poniżej załączam zrzut ekrany z pięknie działającego symulatora :)

    WinAVR toolchain, makefile, programator i symulacja w Atmel Studio 7 [Poradnik]


    6. Programowanie mikrokontrolera

    Jeśli w symulacji wszystko działa jak należy i chcemy zaprogramować nasz uC, to zmieniamy profil na Release i klikamy w ikonę Build. Na załączonym zrzucie, w oknie Output widać, że zawartość pliku led_blink.hex została wgrano i poprawnie zweryfikowana. Wszystko to z poziomu Atmel Studio, bez wykorzystywania dodatkowych narzędzi (*w sposób jawny) i to "niewspieranym" programatorem 8-)
    [*dodatkowe narzędzie w postaci AVRDUDE wykorzystywane jest w tle dzięki zastosowaniu zewnętrznego pliku makefile]

    WinAVR toolchain, makefile, programator i symulacja w Atmel Studio 7 [Poradnik]

    Oczywiście nic nie szkodzi, żeby wgrać korzystać z programatora wspieranego przez Atmel Studio. Trzeba tylko odpowiednio skonfigurować opcje w zakładce Selected debugger/programmer. W takim przypadku flash, eeprom, fuse-bit oraz lock-bit programuje się normalnie z poziomu Atmel Studio, a nie przez makefile.

    PS

    Mam nadzieję, że poradnik się komuś przyda. Jeśli nie, to przynajmniej ja nie będę musiał się głowić w przyszłości jak to zrobiłem :wink:
  • PCBway
  • Poziom 17  
    koleszka napisał:
    Jeśli będzie ktoś zainteresowany, to mogę załączyć przykłady takich skrypt oraz opisać sposób na automatyczne generowanie daty/czasu kompilacji programu i zapis tych informacji do pamięci flash/eeprom.

    Samą datę i czas kompilacji łatwo umieścic w kodzie (__DATE_ __TIME__) ale licznik kompilacji to ciekawa rzecz. Z chcęcią dowiedziałbym sie jak to zrobić.
  • PCBway
  • Poziom 37  
    Cytat:
    Wszystko to z poziomu Atmel Studio, bez dodatkowych narzędzi i to "niewspieranym" programatorem 8-)

    To jest naciąganie prawdy. Sam makefile jest narzędziem gdyż definiuje co na danych etapach robić i czym, a drugim jest avrdude obsługujący owy "niewspierany programator" zatem jak najbardziej jest to z poziomu AS z dodatkowymi narzędziami. Niemniej komuś się to może przydać.
  • Poziom 24  
    Kolego tronics myślę, że się trochę czepiasz.... Przecież w poradniku jawnie napisałem, że do zaprogramowania uC wykorzystamy makefile i AVRDUDE. Miałem na myśli fakt, że nie ma potrzeby uruchomiania żadnego dodatkowego narzędzia w sposób jawny, chociażby korzystania z dodatkowego GUI dla AVRDUDE, aby zaprogramować uC. Przytoczony przez Ciebie fragment został sprecyzowany i poprawiony, tak aby nie było się do czego przyczepić.

    W całym poradniku chodzi głownie o wykorzystanie symulatora wbudowanego w AS i możliwość uruchomienia w nim projektów przeniesionych "żywcem" z WinAVR.

    Dodano po 1 [godziny] 5 [minuty]:

    NoweMillennium napisał:
    Samą datę i czas kompilacji łatwo umieścic w kodzie (__DATE_ __TIME__) ale licznik kompilacji to ciekawa rzecz. Z chcęcią dowiedziałbym sie jak to zrobić.


    W tym celu będzie nam potrzeby niewielki skrypt o nazwie counter.sh, który w pliku build_counter.txt będzie przechowywał licznik kompilacji.
    Kod: actionscript
    Zaloguj się, aby zobaczyć kod
    Skrypt dodatkowo wygeneruje plik build_counter.h, który będzie zawierał następujący kod
    Kod: c
    Zaloguj się, aby zobaczyć kod
    , gdzie za x zostanie wstawiony aktualny licznik kompilacji z pliku build_counter.txt.

    W pliku makefile musimy dopisać kilka linijek kodu odpowiedzialnych za wywołanie skryptu i wyświetlenie stanu licznika kompilacji.
    Kod: makefile
    Zaloguj się, aby zobaczyć kod
    Jeśli EDIT_MODE = FALSE, to licznik nie jest inkrementowany. Przydatne, gdy kończymy edycje programu i nie chcemy zmieniać jego wersji build, przy ponownej kompilacji.

    Jeśli chcemy wykorzystać nasz licznik kompilacji, do automatycznego generowania wersji i daty kompilacji, to możemy sobie napisać plik nagłówkowy o nazwie version.h i dolaczyć go do naszego projektu.
    Kod: c
    Zaloguj się, aby zobaczyć kod
    Po niewielkiej modyfikacji możemy wrzucić licznik kompilacji również do pamięci EEPROM. Przykładowy plik makefile wraz ze skryptem oraz version.h wrzucam w załączniki.
    Załączniki:
  • Poziom 33  
    Jeszcze datę i czas mógłbym zrozumieć. Ale po co ten cały licznik kompilacji? Jaki to ma sens?

    BTW: WinAVR to toolchan, który ma ponad 8 lat.
  • Poziom 24  
    Jaki sens? Tak się składa, że całkiem logiczny. Co Ci po samej dacie kompilacji? Wystarczy, że masz kopie danego projektu i/lub poarchiwizowane wersje programu, po otwarciu poprzedniej wersji i wciśnięciu build data przeskoczy na aktualna. Jak w takim przypadku dojdziesz która wersja była nowsza i ostatnia, będziesz porównywał kod w pliku, datę modyfikacji/utworzenia? Natomiast stan licznika kompilacji jednoznacznie określa która wersja programu jest najnowsza. Dodatkowo mając makro EDIT_MODE, po wydaniu aktualnej wersji możesz przestać inkrementować ten licznik, a przed wgraniem do urządzenia dać build i wiesz kiedy urządzenie zostało zaprogramowane. W praktyce bardzo się to przydaje, o czym sam się przekonałem, zwłaszcza gdy piszesz program, który wgrywasz do wielu urządzeń.
  • Poziom 33  
    No wlaśnie trochę wynajdujesz koło na nowo. Istnieje coś takiego jak systemy kontroli wersji (np GIT), które to załatwiają dosłownie wszystkie Twoje problemy. Dodatkowo sam build counter dostarczają narzędzia do CI, np Jenkins. Wszystko co tu opisujesz to jakaś starożytna metoda rozwoju oprogramowania, która jest po prostu niewydajna i niebezpieczna. A wszystkie powyższe problemy zostały już dawno temu rozwiązane.

    Samo wersjonowanie też masz źle:
    https://semver.org/
  • Poziom 24  
    Co do tworzenia wersji, to jest to przykład, a wystarczy zamienić jedynie RELASE na PATCH i wszystko się zgadza. Nie jest to jedyna konwencja i wiele projektów używa w nazwie wersji build-a. Z resztą zgadza się, jet to metoda archaiczna, którą przygotowałem sobie dość dawno na podstawie artykułu z Wikipedii. Natomiast sam skrypt napisałem na podstawie podobnego, załączonego do innego projektu napisanego w WinAVR.
    grko napisał:
    Dodatkowo sam build counter dostarczają narzędzia do CI, np Jenkins.

    Świetnie, bardzo chętnie przeczytam poradniki jak to zintegrować z Atmel Studio :) Napiszesz taki?
  • Poziom 33  
    Cała koncepcja Twojego build counter i tak legnie w gruzach jak sobie projekt umieścisz w 2 miejscach na dysku i przypadkiem jedno i drugie sobie zbudujesz. Jeden i drugi build mają ten sam build counter ale różne daty. Powiesz mi, który jest ważny/aktualny? Dlatego w rozsądnych projektach stosuje się systemy kontroli wersji. Wtedy taka wersję oznaczasz sobie przykładowo tak:
    1.0.0-bcd6712

    Gdzie ostatni człon to GIT shorthash, czyli unikalna (jak na nasze potrzeby) część SHA-1 danej wersji oprogramowania. Wtedy, bardzo łatwo możesz sobie powiązać plik wynikowy (binarny) z wersją źródeł w systemie kontroli wersji. Żadna data i czas ani nawet numer builda nie są potrzebne. Ale jak już chcesz mieć ten numer builda to zrób sobie np Jenkinsa. Taki CI ma jeszcze jedną ważną zaletę. Produkowane buildy przez taką maszynę używają zawsze tych samych narzędzi. Ma to sporą zaletę w stosunku do buildów generowanych lokalnie raz przez programistę nr 1 a raz przez programistę nr 2.

    No i jeszcze jedna rzecz na którą już zwracałem uwagę. Jaki jest sens używania toolchaina z prehistorii? Microchip przecież udostępnia w miarę aktualne toolchainy na swoich stronach.
  • Poziom 24  
    grko napisał:
    Cała koncepcja Twojego build counter i tak legnie w gruzach jak sobie projekt umieścisz w 2 miejscach na dysku i przypadkiem jedno i drugie sobie zbudujesz. Jeden i drugi build mają ten sam build counter ale różne daty. Powiesz mi, który jest ważny/aktualny?

    Czy ty na siłę chcesz się sprzeczać, po to żeby napić sobie postów, czy jak? Jeśli będę pracował nad jednym projektem, robił zmiany, testy itd, to build counter zawsze będzie znacznie wyższy! Jeśli build jest ten sam, a data się różni, co musiało by być wielkim zbiegiem okoliczności, to znaczy, że aktualny jest ten z najnowszą datą! W takim przypadku pracowałem nad jednym projektem, a później się cofnąłem i tamte zmiany należy porzucić.

    grko napisał:
    Dlatego w rozsądnych projektach stosuje sie systemy kontroli wersji. Wtedy taka wesję oznaczasz sobie przykładowo tak:
    1.0.0-bcd6712
    Gdzie ostatni człon to GIT shorthash, czyli unikalna (jak na nasze potrzeby) część SHA-1 dnej wersji oprogramowania. Wtedy, bardzo łatwo możesz sobie powiązać plik wynikowy (binarny) z wersją źródeł w systemi kontroli wersji. Żadna data i czas ani nawet numer builda nie są potrzebne. Ale jak już chcesz mieć ten numer builda to zrób sobie np Jenkinsa. Taki CI ma jeszcze jedną ważną zaletę. Produkowane buildy przez taką maszynę używają zawsze tych samych narzędzi. Ma to sporą zaletę w stosunku do buildów generowanych lokalnie raz przez programistę nr 1 a raz przez programistę nr 2.

    Proszę bardzo, napisz jak to podpiąć pod Atmel Studio, a tak jak pisałem, chętnie skorzystam. Byle to nie był przerost formy nad treścią, bo cały czas mówimy tutaj o projektach na uC!

    grko napisał:
    No i jeszcze jedna rzecz na którą już zwracałem uwagę. Jaki jest sens używania toolchaina z prehistorii? Microchip przecież udostępnia w miarę aktualne toolchainy na sowich stronach.

    Czy ty w ogóle przeczytałeś o czym jest ten poradnik?

    koleszka napisał:
    Przyczyna jest dość prosta, zwyczajnie miałem potrzebę zaimportowania swoich projektów do nowego środowiska. Oczywiście można skorzystać z eclipse, jednak problem jest z symulatorem. (...) Oczywiście klepanie programów w Programmers Notepad nie jest zbyt wygodne, zwłaszcza w porównaniu z tym, co oferują współczesne platformy. Nie jestem zwolennikiem posiadania kilku środowisk i przeskakiwaniu między nimi, a symulator może być bardzo przydatny, dlatego postanowiłem znaleźć sposób na przeniesienie projektów bezpośrednio do najnowszego Atmel Studio. Mogą się tutaj pojawić opinie, że łatwiej było by przenieść sam kod do nowego projektów. Niestety nie jest to takie proste, pomijając nawet kłopoty przy ponownej kompilacji. Jeszcze większe schody pojawiają się, gdy korzysta się z rozbudowanego pliku makefile, gdzie w zależności od jednego z parametrów, dokonuje się kompilacji warunkowej aby wygenerować wsad dla odpowiedniego urządzenia.

    Po forach jest dużo projektów, przykładów i bibliotek używających makr, czy funkcji nie działających w Atmel toolchain. Cała idea polega na tym, że jeśli ktoś ma potrzebę, to może sobie to wszystko zintegrować z aktualnym Atmel Studio i korzystać nawet z symulatora. Więc czego nie rozumiesz?

    Dodano po 7 [minuty]:

    grko napisał:
    BTW: WinAVR to toolchan, który ma ponad 8 lat.

    Proszę bardzo link do filmiku, jak widać istniała taka potrzeba, dlatego dodano możliwość podpięcia go w AS.
  • Użytkownik usunął konto  
  • Poziom 24  
    J_23_666 napisał:
    Hejka
    @koleszka odkrycie na miarę Einsteina!!!. Ja też mam stare rupiecie w domu , mogę Ci podesłać. Świat poszedł do przodu i na necie można znaleźć pełno wyjaśnień jak przejść z WinAvr na nowszy Toolchain. Z avrdude w Atmel Studio też nie ma problemów. Zastanawia mnie tylko kto dziś wie jak napisać plik makefile?


    Jeśli urządzenie jest w sprzedaży i jeszcze przez długi czas będzie, a ty masz program dobrze przetestowany, który działa bez zarzutu, to po co przenosić? Mając na tym realny zysk, jaki sens jest w przenoszeniu projektu i ryzykowanie, że po pozbyciu się wszystkich błędów kompilacji urządzenia nadal będzie pracowało tak jak trzeba? Jeśli coś jest niezawodne, to się tego nie zmienia! Więc twoim zdaniem, jak masz działające urządzenie, to je wywalasz, bo jest stare i kupujesz nowe, bo jest nowe? :D Dla mnie stare projekty mają działać tak jak działają, a nowe pisze bezpośrednio w Atmel Studio, coś Ci się w tym nie podoba?