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

[ARM] programowanie użytkowanie doświadczenia

And! 04 Lut 2009 11:58 141868 267
  • #181 04 Lut 2009 11:58
    251mz
    Poziom 18  

    Chodzi mi głównie o moc tego procesora...
    potrzebuję go tylko i wyłącznie ze względu na możliwe jak najszybsze wykonanie pewnych obliczeń(konkretnie szybkie przeliczanie PIDa + komutacja elektroniczna dla serwa PMSM).
    zastanawiałem się jeszcze nad AT91SAM9XE gdyż jest lepszy od 9260 i ma flash , lecz nie widzę aby był choć trochę dostępny w Polsce (mowa o kostce a nie o SK).
    no i ciekawe jaka jest jego cena ...

    ze względu iż bawiłem się w 8bit atmele chciałbym już pociągnąć dalej po tej samej firmie...

  • #182 27 Maj 2009 19:10
    Obleśny Szczur
    Poziom 17  

    Podepnę się pod temat z następującym problemem:
    Wraz z kolegami z uczelni z koła naukowego budujemy model lokomotywy sterowanej zdalnie, w którym chcemy odtworzyć wszystkie podzespoły dość realnie i zgodnie z najnowszymi trendami i rozporządzeniami w dziedzinie kolejnictwa, bla bla bla...
    W związku z tym pomysł jest taki aby ARM pracował jako jednostka centralna a do niego będzie podpięte kilka avr-ów (z nimi komunikacja po SPI, da się tak??) obsługujących np moduł sterowania silnikami, hamulcami, przetwornicą itd. oraz co najważniejsze - do ARM podłączony będzie moduł komunikacji bezprzewodowej oraz jakieś 2 bardzo prymitywne czarno-białe kamerki - wiem że pewnie sam ARM pociągnął by wszystko, ale musimy trzymać się koncepcji modułowej budowy nowoczesnej lokomotywy, gdzie każdy moduł ma swój własny mózg :)
    Pytanie który ARM będzie do tego najodpowiedniejszy w miarę przystępnej dla studenta cenie :) Musi on zebrać/wysłać dane po SPI, odebrać obraz z dwóch kamerek, a potem to wszystko wysłać do modułu komunikacji bezprzewodowej i odebrać z niego rozkazy sterujące pojazdem.
    Na stanowisku operatora będzie drugi ARM, do niego podpięta masa przełączników, kontrolek i wskaźników oraz LCD który wyświetli obraz z kamer no i oczywiście drugi moduł do komunikacji.
    Mam nadzieję, że nie namieszałem za bardzo i taki system jest w ogóle wykonalny :)

  • #183 28 Maj 2009 10:25
    Zaquadnik
    Poziom 27  

    Z tymi kamerkami to trochę zabawy. Co to znaczy zbierać obraz ? Co na wyjściu daje kamerka ? Ile klatek na sekundę ? Czy ma przeprowadzać kompresję MPEG w locie ?

    Na początek coś z rdzeniem Cortex-M3, albo Cortex-A8 (drogi, ale wydajny), ew. coś opartego o rdzeń ARM9.

  • #184 28 Maj 2009 16:13
    Obleśny Szczur
    Poziom 17  

    Znaczy się przesyłać obraz w czasie rzeczywistym, co kamerka daje i ile klatek nie wiem, bo jeszcze jest nie wybrany żaden konkretny model, ale na pewno będzie to coś naprawdę najprostszego, bez żadnej kompresji.
    Może coś w tym stylu:
    http://www.mdm-system.pl/product-pol-2704-Kamera-TVCCD30M.html
    Naprawdę nie da się tego zrobić na jakimś ARM7? Trzeba od razu sięgać po takie rdzenie jak Cortex-M3? A gdyby tak uprościć sprawę i przełączać się między kamerkami, żeby był przesyłany obraz tylko z jednej?

  • #185 28 Maj 2009 16:39
    Zaquadnik
    Poziom 27  

    Kwestia rozdzielczości obrazu. Dajmy na to obraz w rozdzielczości 320x240 (a więc marnej) i 8-mio bitowej skali szarości. 1 klatka zajmuje 320*240 bajtów, czyli 75kB, chcesz mieć obraz w czasie rzeczywistym, a więc co najmniej 20 FPS czyli masz 20*75kB = 1500 kB, czyli 1,46 MB/s. Teraz chcesz przesyłać obraz z 2 kamerek, czyli musisz przesyłać (i obrabiać) dane z szybkością 2,92 MB/s, a to sporo. I mówimy tu o marnej rozdzielczości kamerki. Moim zdaniem ARM7 mógłby mieć problem, chociaż można spróbować. Z tym, że licz się, że bez kompresji będzie dość duży strumień danych, z którymi coś trzeba zrobić. A o przesyłaniu drogą radiową raczej zapomnij. Ta kompresja to właśnie po to, żeby przepchnąć to szystko bezprzewodowo. Nasuwa mi się na myśl układzik i.MX31 od Freescale, to jest potwór, rdzeń ARM11, ogromna moc obliczeniowa i do tego sprzętowy koder MPEG-4, ale to już jak strzelanie z armaty do wróbla =]

  • #186 28 Maj 2009 17:00
    Obleśny Szczur
    Poziom 17  

    Hmmm ale w sumie chyba z takiej kamery przemysłowej jak w linku sygnał jest analogowy, czy nie da się go przesłać w ten sposób:
    kamera->przetwornik a/c->ARM nr1->łączę bezprzewodowe->ARM nr2->przetwornik c/a->ekran

  • #187 28 Maj 2009 17:31
    Zaquadnik
    Poziom 27  

    Da się, ale sprawdź najpierw z jaką częstotliwością musisz próbkować sygnał z kamerki.

  • #188 28 Maj 2009 19:38
    Obleśny Szczur
    Poziom 17  

    Więc dla tej kamerki z linku, przy odświeżaniu poziomym 15625Hz i rozdzielczości w poziomie powiedzmy 320 punktów sygnał trzeba próbkować z częstotliwością 10MHz. Wydaje mi się, że to chyba sporo Tym bardziej że jak wyczytałem z noty katalogowej AT91SAM7 maksymalna częstotliwość próbkowania wynosi 8MHz.

  • #189 03 Cze 2009 22:05
    Zaquadnik
    Poziom 27  

    Und hier liegt ein Hund begraben - jak to mawiają Niemcy =P. Najpierw musisz zdobyć odpowiedni przetwornik, potem obróbka danych, hmmm, nie wiem czy ARM7 się wyrobi. Nie wiem czy Cortex wystarczy. ALe warto sprawdzić.

  • #190 27 Lip 2009 19:58
    atom1477
    Poziom 43  

    A nie lepiej po prostu zastosować kamerę cyfrową? Odchodzi konieczność separowania impulsów synchronizacji i konwersji A/C.
    Jakąś z telefonu komórkowego (od CX65 albo S65 – te są opisane).
    Albo słynną i bardzo przyjazną w obsłudze PO3030.
    A w ostateczności nawet MCA-25. Ta od razu kompresuje do JPEGów.

    A jak już analogową, to kup jakąś na allegro. Czarno białe są po 30zł. Po co płacić aż 180zł?

  • #191 01 Paź 2009 22:27
    Petros
    Poziom 20  

    witam

    sorry że odkopuje ale nie chciałem zakładać nowego tematu. Dzisiaj postanowiłem zamienić AVR na ARM i mam kilka pytań mimo że przeczytałem cały temat
    1. Dużo pisane było o środowiskach ale ja dalej nie wiem co sie nadaje. Chodzi mi o programowanie w C dla AT91xxx ewentualnie LCP bez jakiś symulatorów itp.. ważne aby wywaliło hex'a i był edytor z kompilatorem. Jak skąfigurować to Eclipse?
    2. Jakie są możliwe drogi zaprogramowania AVR?? RS232, JTAG z LPT, USB, coś jeszcze która metoda jest najbardziej niezawodna i sprawdzona?
    3. O co chodzi z programowaniem pamięci Flasch i wewnętrznej ? Myślałem że to to samo
    4. O co chodzi z trybem THUMB ?
    5. Reszta jest podobna do AVR? Co jeszcze znacząco odróżnia ARM np od AVR?

    sorry za lamerskie pytania ale musze jakoś wystartować, może ma ktoś jakieś linki z wiedzą abym mógł sie douczyć i już was nie dręczyć...

    dzięki pozdrawiam

  • #192 01 Paź 2009 22:49
    atom1477
    Poziom 43  

    1. Ze stroy Freddiego Chppina?
    http://www.freddiechopin.info/index.php/pl/artykuly/35-arm/59-arm-toolchain-tutorial
    2. Chyba ARM. Po RS232 FlashMagikiem (FlashMagic). LPT – Wigglerem. Działa też na przejściówkach PCMCIA. USB – JTAG Freddiego Chopina.
    3. Bo to to samo ;p
    4. THUMB to instrukcje 16-to bitowe. Program będzie zajmował mniej pamięci i nawet szybciej się wykonywał (więcej krótszych instrukcji zmieści się w buforze, niż instrukcji długich). Ale nie wszystkie instrukcje mogą być 16-to bitowe. Więc THUMB ogranicza trochę możliwości pisania (albo optymalizacji) programu. Więc nie zawsze THUMB jest takie superowe.
    5. Z jednej strony różnica jest kolosalna. Ale z drugiej jak piszę na ARM to wielkiej różnicy nie widzę. Ja też dopiero zaczynam z ARMami. Coś piszę, if, while, for, jak na AVRa. Trzeba jakieś peryferia ustawić, to zaglądam do Datasheeta, tyle że do ARMa a nie AVRa. Taka różnica.
    O wiele większa różnica jest taka, że AVRy są dobrze opisane i są jedne. ARMy są różne. Produkuje je chyba każdy. Jedne dokumentacje są lepsze inne gorsze. Ilość informacji o ARMach na elektrodzie jest mizerna, i chyba to jest największa różnica jeżeli chodzi o przerzucenie się z AVR na ARMy.
    Acha. ARMy mają architekturę Von'Neumana, więc można uruchamiać programy z pamięci RAM. I w ogóle z pamięci zewnętrznej. Mają różne tryby ochrony (pamięci, stosu – chyba ;p).
    Czyli różne systemy operacyjne czy coś pójdzie na nich 1000 razy lepiej niż na AVR. Na AVR system operacyjny pójdzie, ale tylko taki gdzie programy są na stałe zaszyte w pamięci programu.
    Pomijam ogromną różnicę w mocy obliczeniowej ;p

  • #193 01 Paź 2009 22:49
    Freddie Chopin
    Specjalista - Mikrokontrolery

    Petros napisał:
    1. Dużo pisane było o środowiskach ale ja dalej nie wiem co sie nadaje. Chodzi mi o programowanie w C dla AT91xxx ewentualnie LCP bez jakiś symulatorów itp.. ważne aby wywaliło hex'a i był edytor z kompilatorem. Jak skąfigurować to Eclipse?

    Szukałeś? Wątpie... https://www.elektroda.pl/rtvforum/topic1313509.html

    Cytat:
    2. Jakie są możliwe drogi zaprogramowania AVR?? RS232, JTAG z LPT, USB, coś jeszcze która metoda jest najbardziej niezawodna i sprawdzona?

    Szukałeś? Wątpie... Choćby tutaj dobre kilka stron... https://www.elektroda.pl/rtvforum/topic1191756.html

    Cytat:
    3. O co chodzi z programowaniem pamięci Flasch i wewnętrznej ? Myślałem że to to samo

    Flash może być zewnętrzny, niemniej jednak mechanizm taki sam - JTAG / bootloader.

    Cytat:
    4. O co chodzi z trybem THUMB ?

    O co chodzi z tym, że ludzie najpierw pytają, a potem szukają? http://www.google.pl/search?client=opera&rls=pl&q=ARM+thumb&sourceid=opera&ie=utf-8&oe=utf-8

    Cytat:
    5. Reszta jest podobna do AVR? Co jeszcze znacząco odróżnia ARM np od AVR?

    Wszystko?

    Cytat:
    sorry za lamerskie pytania ale musze jakoś wystartować, może ma ktoś jakieś linki z wiedzą abym mógł sie douczyć i już was nie dręczyć...

    Z Twoich pytań widzę chęć wystartowania "od razu" i "od dziś". Z takim podejściem daj sobie spokój od razu - to nie są zabawki które opanujesz w 2 wieczory. Prędzej miesiące (i to raczej nie dwa) jeśli nie lata.

    4\/3!!

  • #194 01 Paź 2009 22:57
    atom1477
    Poziom 43  

    Freddie Chopin napisał:
    Flash może być zewnętrzny, niemniej jednak mechanizm taki sam - JTAG / bootloader.


    Chcesz powiedzieć że jak podłączę sobie Flasha AT49BV642 to normalnie JTAGiem mogę go zaprogramować? ARM sam się zajmie odpowiednimi opóźnieniami czasowymi, jak również kasowaniem sektorów? Skąd ma wiedzieć jaka jest organizacja zewnętrznej pamięci oraz jakie komendy pamięć obsługuje (komendy kasowania kolejnych sektorów)?
    Strasznie by mnie to ratowało, bo już chciałem zrezygnować z AT49BV642 i zastosować kartę SD. A dla przyspieszenia odczytu zastosować kopiowanie zawartości karty SD do pamięci SDRAM, i późniejsze korzystanie już tylko z pamięci SDRAM.

  • #195 01 Paź 2009 23:03
    Freddie Chopin
    Specjalista - Mikrokontrolery

    atom1477 napisał:
    2. Chyba ARM. Po RS232 FlachMagikiem (FlachMagic).

    FlashMagic jest tylko dla LPC2xxx, ale każdy (?) mikrokontroler z rdzeniem ARM ma bootloader i do każdego jest jakiś program. Bootloadery z komunikacją po UART albo USB, są też bardziej kosmiczne opcje (CAN / Ethernet).

    Cytat:
    3. Bo to to samo ;p

    Jak napisałem powyżej - wcale nie musi tak być.

    Cytat:
    4. THUMB to instrukcje 16-to bitowe. Program będzie zajmował mniej pamięci i nawet szybciej się wykonywał (więcej krótszych instrukcji zmieści się w buforze, niż instrukcji długich).

    Szybsze to one na pewno nie są, bo są mniej "złożone" niż zwykłe instrukcje ARM. Nie dotyczy to trybu Thumb-2, który wydaje się być do trybu ARM conajmniej (!) porównywalny. Rozmiar bufora (cokolwiek by to nie było) też nie ma specjalnego znaczenia, bo ARM7 nie ma cache.

    atom1477 napisał:
    Chcesz powiedzieć że jak podłączę sobie Flasha AT49BV642 to normalnie JTAGiem mogę go zaprogramować? ARM sam się zajmie odpowiednimi opóźnieniami czasowymi, jak również kasowaniem sektorów? Skąd ma wiedzieć jaka jest organizacja zewnętrznej pamięci oraz jakie komendy pamięć obsługuje (komendy kasowania kolejnych sektorów)?
    Strasznie by mnie to ratowało, bo już chciałem zrezygnować z AT49BV642 i zastosować kartę SD. A dla przyspieszenia odczytu zastosować kopiowanie zawartości karty SD do pamięci SDRAM, i późniejsze korzystanie już tylko z pamięci SDRAM.

    Flash RÓWNOLEGŁY podłączysz tylko do mikrokontrolerów z magistralą (to oczywiste), niemniej jednak po skonfigurowaniu kontrolera takiej pamięci mechanizm programowania jest RACZEJ (nie mam doświadczenia, czysta hipoteza) taki sam - przez JTAGa i OpenOCD albo przez własnoręcznie napisany bootloader (firmowe raczej nie obsługują dodatkowych przestrzeni adresowych, ale mogę się i tu mylić).

    4\/3!!

  • #196 01 Paź 2009 23:18
    atom1477
    Poziom 43  

    3. Źle zrozumiałem pytanie, stąd moja nieścisła odpowiedz.
    4. Załóżmy że chodzi nie tylko o ARM7 (w sumie nigdzie, nawet w temacie tego tematu (fajnie to brzmi) też nie pisze).
    Ale w ARM7 (LPC2k) jest na przykład MAM. On trochę buforuje. Chyba THUMB pójdzie z niego szybciej. Z ciekawości sprawdzę.

    Po za konkursem: Oczywiście chodziło mi o magistralę równoległą. Jak zwykle o mojego LPC2478 ;p
    Co do karty SD to chodziło mi o to, że ją mogę bezproblemowo "programować" na kompie. A AT45xxx nie. Nawet w żadną podstawkę nie wejdzie, bo ma raster pinów 0,5mm.
    A z tym kontrolerem o co Ci chodzi? Przecież po oruchomieniu bootloadera nie skonfiguruję ukłądu EMC.
    Może przez JTAGa by się dało, skoro na przykład MAM i PLL da się wyłączyć.

  • #197 01 Paź 2009 23:31
    Freddie Chopin
    Specjalista - Mikrokontrolery

    atom1477 napisał:
    Ale w ARM7 (LPC2k) jest na przykład MAM. On trochę buforuje. Chyba THUMB pójdzie z niego szybciej. Z ciekawości sprawdzę.

    MAM na tyle przyspiesza, że tryb ARM jest tak szybki jak przy pracy bez żadnych opóźnień, więc THUMB nie będzie szybszy.

    Cytat:
    A z tym komtrolerem o co Ci chodzi? Przecież po oruchomieniu bootloadera nie skonfiguruję ukłądu EMC.
    Może przez JTAGa by się dało, skoro na przykład MAM i PLL da się wyłączyć.

    Pisałem, że przez firmowy bootloader się nie da, ale nic nie stoi na przeszkodzie, aby napisać własny. Przez JTAGa wszystko się da <:

    4\/3!!

  • #198 01 Paź 2009 23:46
    atom1477
    Poziom 43  

    Freddie Chopin napisał:

    MAM na tyle przyspiesza, że tryb ARM jest tak szybki jak przy pracy bez żadnych opóźnień, więc THUMB nie będzie szybszy.

    No ale jak nie ma pętli, tylko ciąć 1000 instrukcji po sobie, a Flash ma ograniczenie prędkości odczytu, to chyba MAM nic nie pomoże?
    A jak instrukcje będą krótsze, to już tak.


    Freddie Chopin napisał:

    Pisałem, że przez firmowy bootloader się nie da, ale nic nie stoi na przeszkodzie, aby napisać własny. Przez JTAGa wszystko się da <:


    No tak, nie skojarzyłem. Tutaj nawet nie chodzi o przestrzeń adresową, ale o te komendy.
    No to dzięki.
    Sam już nie wiem. Ciekawe jak z trwałością karty SD. Co ciekawe w datasheecie pamięci AT49BV642 nie podali trwałości. A trwałość (katalogową) kart SD to znam. Nie wiadomo tylko jak w praktyce to będzie.

  • #199 02 Paź 2009 07:10
    Freddie Chopin
    Specjalista - Mikrokontrolery

    [quote="atom1477"]

    Freddie Chopin napisał:
    No ale jak nie ma pętli, tylko ciąć 1000 instrukcji po sobie, a Flash ma ograniczenie prędkości odczytu, to chyba MAM nic nie pomoże?
    A jak instrukcje będą krótsze, to już tak.

    Chyba musisz doczytać dokładnie o module MAM [; Jest on tak pomyślany, że pomaga praktycznie na wszystko. Sama idea nie ma też zbyt wiele wspólnego z cache. W Manualu jest to dosyć dobrze opisane, więc można poczytać.

    4\/3!!

  • #200 02 Paź 2009 10:30
    atom1477
    Poziom 43  

    Ale MAM nie ma tutaj nic do rzeczy. Jeżeli procesor chce 72 miliony instrukcji na sekundę, a Flash może dać tylko 18 milionów, to MAM nic nie pomoże, jaki cudowny by nie był.
    Poczytać powinienem, ale nie o MAM lecz o instrukcjach procesora.
    Może wiele z nich jest wielocylkowych i dlatego MAM pomaga (buforuje nowe instrukcje zanim jeszcze procesor wykona poprzednie, choć od tego to chyba potok jest p; ).

  • #201 02 Paź 2009 10:40
    Freddie Chopin
    Specjalista - Mikrokontrolery

    Naprawdę powinieneś poczytać o MAM, zamiast zakładać, że wiesz wszystko w tej sprawie...

    Flash owszem - zapewnia 18M, ale nie instrukcji, a ODCZYTÓW. Wewnętrzny Flash w LPC2xxx ma fizycznie 128bitową szynę i mam odczytuje jednocześnie 4 rozkazy ARM lub 8 rozkazów Thumb, a więc umożliwia ci wystarczającą przepustowość 72M instrukcji ARM. Do tego MAM sciąga instrukcje nie tylko sekwencyjnie, ale i przewiduje możliwe skoki i jednocześnie ściąga rozkazy spod lokacji która może być bieżącą po skoku warunkowym. Jest też bufor, który ściąga dane znajdujące się w pamięci Flash.

    4\/3!!

  • #202 02 Paź 2009 10:49
    atom1477
    Poziom 43  

    A. No to co innego.
    Co do skoków to już MAM nie wiele pomoże, bo musi odczytać program z innego adresu. Tak by ściągnął 4 instrukcje za jednym razem, a tak musi na przykład 2 z jednych 128bitów a drugie dwie z drugich 128bitów. Nie licząc tego że potok będzie musiał zostać przepłukany (ARM chyba nie ma podwójnego potoku?) więc ta zwłoka układu MAM i tak nie zostanie zauważona.
    Nie zawsze, ale czasami tak może być.

    PS1. Przeczytałem to jeszcze kilka razy a nawet wkleiłem do translatora, a dalej nie rozumiałem ;p Więc dzięki za wyjasnienie ;p
    PS2. Acha. Już rozumiem. Po prostu rozdział o MAM nie wyjaśnia tego że FLASH ma szynę 128bitową. Pisali o buforach 128bitowych, ale ja myślałem że do jego pobrania trzeba 4 odczyty. No i dziwiłem się po co w takim razie bufor 128bitowy.
    Więc sorki za zamieszanie.
    Miałem też inne nietypowe teorie, ale na szczęście już je rozwiązałem sam (i tym samym oszczędziłem śmietnika na elektrodzie ;p) Na przykład dlaczego ARM mając 32bity adresu może zaadresować tylko 4BG pamięci a nie 16GB, (bo adresuje co bajt a nie co słowo).

  • #203 03 Paź 2009 13:26
    Petros
    Poziom 20  

    Dzięki za odpowiedzi i linki. Bede czytał. Wiem że w 2 dni niczego nie opanuje.. Ale może zdziałam coś w 2 miesiące, narazie zbieram literature i próbuje wybrać środowisko + soft do programowaniem.
    Czy dokumentacje atmela faktycznie są tak fatalne że lepiej zająć sie produktami Philips'a?
    Skoro tak mało źródeł wiedzy na temat AVR na elce to może umieścimy tutaj najbardziej konkretne linki

  • #204 03 Paź 2009 13:41
    Freddie Chopin
    Specjalista - Mikrokontrolery

    Petros napisał:
    Czy dokumentacje atmela faktycznie są tak fatalne że lepiej zająć sie produktami Philips'a?

    Jedne są lepsze, drugie są gorsze - problemem jest to, że do AVR wszystko jest w jednym miejscu, do ARMa - w bardzo wielu dokumentach, nie tylko tych od producenta układu, ale też w dokumentacji firmy ARM. Dokumentacja od NXP jest dobra, dokumentacja do ST jest słaba, ale wszystkie są wystarczające.

    Cytat:
    Skoro tak mało źródeł wiedzy na temat AVR na elce to może umieścimy tutaj najbardziej konkretne linki

    Za X miesięcy i tak będą nieaktualne, więc jaki to ma sens? Nawet jeśli same linki będą aktualne, to ich treść może być już nie-dzisiejsza (tak jak z ulubionym przez wszystkich WinARMem i GNUARMem, który jest skrajnie nieaktualny).

    4\/3!!

  • #206 03 Paź 2009 14:43
    Freddie Chopin
    Specjalista - Mikrokontrolery
  • #207 03 Paź 2009 14:51
    Petros
    Poziom 20  

    sorry nie dałem linka do książki..

    http://www.btc.pl/?id_prod=6036600 co o niej sądzicie?

    Widze z opisu że twoja konfiguracja jest bardziej elastyczna. Ale czyn WinARM wystarzy na początek?

    W elektronice dla wszystkich jest Kurs na temat ARM w numerach 12.2005 - 5.2006. Można kupić archiwa płacąc sms? Ale nie mam opisu tych artykółów, wie ktoś co tam piszą?

  • #208 03 Paź 2009 15:04
    atom1477
    Poziom 43  

    Ale po to Ci WinARM żeby potem przechodzić na coś lepszego? Nie lepiej od razu zacząć od lepszego?
    Ja byłem wielkim przeciwnikiem C a dzięki Freddiemu Chopinowi i jego tutarialowi już kolorowy LCD na ARMie odpalam (pomagali też inni ale chodzi o samo środowisko programowania).
    Więc jeżeli chodzi o łatwość konfiguracji to to co masz podane na stronie Freddiego Chopina jest łatwe, skoro i ja to uruchomiłem.

  • #209 03 Paź 2009 15:29
    Freddie Chopin
    Specjalista - Mikrokontrolery

    Petros napisał:
    Widze z opisu że twoja konfiguracja jest bardziej elastyczna. Ale czyn WinARM wystarzy na początek?

    Czy Windows 95 wystarczy na początek? Jeśli będziesz mieć jakiś problem (a będziesz mieć, bo każdy ma i to nie jeden), to ja osobiście odpowiem, że masz zbyt starą wersję kompilatora. Więc jeśli usilnie wolisz walczyć z bugami, które usunięto na przestrzeni ostatnich 3 lat, to nic nie stoi na przeszkodzie, abyś używał WinARMa albo GNUARMa.

    4\/3!!

  • #210 03 Paź 2009 16:01
    Petros
    Poziom 20  

    Freddie masz racje ! Ten WinARM nie był ruszany od roku 2006. Jenak pójdę twoją drogą :) Szkoda tylko że ktoś tak ciekawą książke opiera na WinARM, przykłady pewnie nie zadziałają? Musze jeszcze poszukać jakiś kursów o ARM na temat portów I/O, przerwań itp bo widze że inaczej to wygląda niż w AVR