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

Jaki lepszy uC dla początkującego w ARM (LPC 2368 czy 1769)

PietrekDer 20 Paź 2010 23:12 3037 13
  • #1 20 Paź 2010 23:12
    PietrekDer
    Poziom 13  

    Witam
    Mam pytanie odnośnie jaki procek byłby lepszy dla osoby, która chce poznać mikrokontrolery ARM, a do tej pory zajmowała się jakimiś AVRkami czy PICami (ogólnie prostymi 8-bitowcami). Do wyboru jest albo LPC2368 z rdzeniem ARM7TDMI albo LPC1769 z rdzeniem Cortex-M3. Przeglądając ogólne specyfikacje w propoxie (bo tam mam zamiar zamówić) LPC1769 wydaje się lepszym prockiem, może działać szybciej i ma np HOST USB. Jednak słyszałem opinie że ogólnie trudniej zaczyna się zabawę z prockami z rdzeniem Cortex-M3 niż z ARM7TDMI. No i jeszcze jedno kryterium, może mniej ważne, ale chciałbym korzystać tylko z darmowego oprogramowania do obsługi procka (kompilacja, programowanie itd), i nie wiem czy z jakimś prockiem nie byłoby problemów w tej kwestii.

    Z góry dziękuję za odpowiedź i pozdrawiam.

    0 13
  • CControls
  • #2 20 Paź 2010 23:15
    Freddie Chopin
    Specjalista - Mikrokontrolery

    Którego nie wybierzesz będzie tak samo trudno [; Tego typu wątków jest na pęczki. Ja bym wybrał to, ktoś inny tamto. Każdy ma wady i zalety...

    Oprogramowanie opensource obsługuje jeden i drugi.

    4\/3!!

    0
  • #3 21 Paź 2010 13:14
    nsvinc
    Poziom 35  

    Freddie Chopin napisał:
    Którego nie wybierzesz będzie tak samo trudno

    Absolutnie nie :]

    CortexM3. Popatrzmy chociaż na przerwania...które dzięki NVIC są w zasadzie proste jak budowa cepa i samo pisanie ISRów jest podobne jak dla np. 16bitowych piców czy nawet AVR...
    Samego NVICa na początek nawet nie trzeba rozumieć...

    Drugą zaletą jest jeden zestaw instrukcji który wypada poznać, mianowicie Thumb2. W przypadku ARM7TDMI trzeba poznać dwa zestawy instrukcji, ARM i Thumb, trzeba znać powody dlaczego są dwa i jakie ograniczenia ma Thumb, no i dodatkowo trzeba coś wiedzieć na temat ich interakcji.

    CM3 jest znacznie mniej poplątany niż jakikolwiek ARM7 głownie z dwóch wyżej wymienionych powodów. I ma lepszy i bardziej przejrzysty zestaw instrukcji, a dodatkowo ma parę instrukcji przydatnych do DSP, min. nasycenia i Multiple-And-Accumulate.

    ARM7 jest obecnie wypierany przez CortexyM3, bo ten drugi jest pod każdym względem lepszy.

    0
  • #4 21 Paź 2010 13:22
    Freddie Chopin
    Specjalista - Mikrokontrolery

    nsvinc napisał:
    CortexM3. Popatrzmy chociaż na przerwania...które dzięki NVIC są w zasadzie proste jak budowa cepa i samo pisanie ISRów jest podobne jak dla np. 16bitowych piców czy nawet AVR...
    Samego NVICa na początek nawet nie trzeba rozumieć...

    Czym się różni pisanie ISRów w C dla jednej czy drugiej architektury? Jak dla mnie niczym...

    Cytat:
    Drugą zaletą jest jeden zestaw instrukcji który wypada poznać, mianowicie Thumb2. W przypadku ARM7TDMI trzeba poznać dwa zestawy instrukcji, ARM i Thumb, trzeba znać powody dlaczego są dwa i jakie ograniczenia ma Thumb, no i dodatkowo trzeba coś wiedzieć na temat ich interakcji.

    No na pewno każdy początkujący zacznie od poznawania assemblera ARMów... Zresztą ARM, T1 czy T2 sa tak podobne, że to żadna różnica... Największa różnica to sposób obsługi instrukcji warunkowych, który akurat w T2 jest najbardziej skomplikowany, reszta to detale.

    Cytat:
    CM3 jest znacznie mniej poplątany niż jakikolwiek ARM7 głownie z dwóch wyżej wymienionych powodów. I ma lepszy i bardziej przejrzysty zestaw instrukcji.

    Przy okazji jest mniej książek, artykułów, przykładów i ludzi którzy je znają niż analogicznych dla ARM7. Same rdzenie ARM7 - z racji dłuższej obecności na rynku - mają też mniej błędów.

    Cytat:
    ARM7 jest obecnie wypierany przez CortexyM3, bo ten drugi jest pod każdym względem lepszy.

    Pod pewnymi względami jest lepszy, pod pewnymi jest gorszy. (;

    4\/3!!

    0
  • CControls
  • #5 21 Paź 2010 15:17
    nsvinc
    Poziom 35  

    Hm...

    Freddie Chopin napisał:
    Czym się różni pisanie ISRów w C dla jednej czy drugiej architektury? Jak dla mnie niczym...

    No, załózmy. Na ARM7 piszesz jednego/dwa ISRy, w którch są ify lub switch a dopiero dalej jest właściwy kod obsługujący dane przerwanie. Gdy dysponujemy NVICiem, takich szopek nie ma.
    BTW, CM3 włazi w ISRy ponad dwa razy szybciej niż ARM7/ARM9...

    Freddie Chopin napisał:
    No na pewno każdy początkujący zacznie od poznawania assemblera ARMów[...]

    No ja poznając nowy rdzeń zacząłbym od zapoznania się z zestawem instrukcji...

    Freddie Chopin napisał:
    Największa różnica to sposób obsługi instrukcji warunkowych, który akurat w T2 jest najbardziej skomplikowany[...]

    Chodzi Ci najpewniej o instrukcję IT i jej kombinacje...?
    Ta instrukcja jest cudowna pod wieloma względami, a poza tym jest prosta, i jej sposob uzycia jest oczywisty i logiczny...

    Poza tym, biorąc się za ARM7, wypada znać fakty na temat Thumb - jest dosyć kaleki i oprócz lepszego upakowania kodu maszynowego nie daje zupełnie nic (a raczej marnuje możliwości rdzenia), a patrząc na obecne wielkości flashy, to kto by na to zwracał uwagę...

    Freddie Chopin napisał:
    Pod pewnymi względami jest lepszy, pod pewnymi jest gorszy.

    Podaj przykłady w którym miejscu ARM7 jest lepszy od CM3....?

    0
  • #6 21 Paź 2010 15:35
    Freddie Chopin
    Specjalista - Mikrokontrolery

    nsvinc napisał:
    No, załózmy. Na ARM7 piszesz jednego/dwa ISRy, w którch są ify lub switch a dopiero dalej jest właściwy kod obsługujący dane przerwanie. Gdy dysponujemy NVICiem, takich szopek nie ma.

    Każdy, naprawdę KAŻDY dostępny mikrokontroler z rdzeniem ARM7 ma jakiśtam zintegrowany kontroler przerwań, więc - wciąż - jak dla mnie nie ma różnic między ISRami w LPC2xxx a LPC17xx/STM32/... . Innymi słowy - "takich szopek" nie ma nigdzie.

    Cytat:
    Chodzi Ci najpewniej o instrukcję IT i jej kombinacje...?
    Ta instrukcja jest cudowna pod wieloma względami, a poza tym jest prosta, i jej sposob uzycia jest oczywisty i logiczny...

    Być może, jednak możliwość dodawania conditionali do KAŻDEJ instrukcji w trybie ARM jest bardziej oczywista, bardziej logiczna, bardziej prosta i bardziej cudowna.

    Cytat:
    Poza tym, biorąc się za ARM7, wypada znać fakty na temat Thumb - jest dosyć kaleki i oprócz lepszego upakowania kodu maszynowego nie daje zupełnie nic (a raczej marnuje możliwości rdzenia), a patrząc na obecne wielkości flashy, to kto by na to zwracał uwagę...

    W ogóle nie wiem kto by zwracał uwagę na assembler. Jak piszesz soft na PC to zwracasz uwagę na assembler?

    Cytat:
    Podaj przykłady w którym miejscu ARM7 jest lepszy od CM3....?

    Więcej materiałów (zarówno papierowych jak i w necie). Więcej osób znających się na nich. Większy wybór układów, które są bardziej dopracowane, bo to już któraś-tam rewizja (czy to samego rdzenia czy też mikrokontrolera), a nie absolutna nowość bez erraty.

    4\/3!!

    0
  • #7 21 Paź 2010 16:06
    nsvinc
    Poziom 35  

    Freddie Chopin napisał:
    Innymi słowy - "takich szopek" nie ma nigdzie.

    No skoro nagle wszystkie ARM7 mają jakiś VIC, no to faktycznie problem nie istnieje :] Ale z tego co pamiętam, to nie wszystkie procki ten VIC mają...

    Freddie Chopin napisał:
    Być może, jednak możliwość dodawania conditionali do KAŻDEJ instrukcji w trybie ARM jest bardziej oczywista, bardziej logiczna, bardziej prosta i bardziej cudowna."

    To swoją drogą...

    Freddie Chopin napisał:
    W ogóle nie wiem kto by zwracał uwagę na assembler. Jak piszesz soft na PC to zwracasz uwagę na assembler?

    A jak piszesz np. funkcję podkolorowującą bitmapę, gdzie aż się prosi uzycie nasyceń to nie zwracasz uwagi na assembler? :]
    Albo jak piszesz w ISRrze PIDa do np. jakiejś przetwornicy to też nie?...
    Kompilatory przecież nie wykorzystują WSZYSTKICH ficzerów rdzeni...

    Freddie Chopin napisał:
    Więcej materiałów (zarówno papierowych jak i w necie). Więcej osób znających się na nich. Większy wybór układów, które są bardziej dopracowane, bo to już któraś-tam rewizja (czy to samego rdzenia czy też mikrokontrolera), a nie absolutna nowość bez erraty.

    Do CM3 jest errata :P No poza tym nie jest to już absolutna nowość - procki na tym rdzeniu istnieją już od paru lat. A jeśli chodzi o ludzi "znających się" - gdzie odczuwasz brak takich ludzi?

    BTW, skoro ARM7 nadal ma tyle zalet i - jak twierdzisz - są bardziej dopracowane, i lepszy support, itp itd, to czemu pracujesz z CM3?...

    0
  • #8 21 Paź 2010 17:07
    tymon_x
    Poziom 30  

    PietrekDer, sam zaczynałem ARM'y właśnie na rdzeniu Cortex-M3 (STM32, później LPC13xx). Niedawno dobrałem się do LPC2138, obsługa prawie taka sama. Ale trzeba przyznać, że VIC było mi trudniej okiełznać niż NVIC, który ten drugi w obsłudze jest bardzo łatwy jak się załapie o "co kamam". Polecam Cortex'y, nowsze, przyjemniejsze i zazwyczaj tańsze. W dodatku jest jego okrojona wersja Cortex-M0 (np. LPC11xx), główny "pogromca" 8-bitowców. W najnowszym EP (10/2010) jest opis środowisk IDE, od płatnych, okrojonych po OpenSource (taki przeglądzik). A co do błędów, to te erraty dotyczą głównie peryferiów dołączonych przez wytwórców uC na tym rdzeniu (np. STM32) lub ich złego opisu.

    Ten rdzeń ma już trochę lat, był na początek dostępny jako rozwojowa implementacja do FPGA.

    0
  • #9 21 Paź 2010 17:10
    Freddie Chopin
    Specjalista - Mikrokontrolery

    nsvinc napisał:
    No skoro nagle wszystkie ARM7 mają jakiś VIC, no to faktycznie problem nie istnieje :] Ale z tego co pamiętam, to nie wszystkie procki ten VIC mają...

    Dwie najpopularniejsze rodziny - LPC2xxx i AT91SAM7 - mają takie kontrolery, a pytanie z tematu było dodatkowo o w miare popularny i rozbudowany układ, więc... Pewnie znajdzie się jakiś egzotyczny ARM7 który takiego kontrolera nie ma, ale na 99,666% nikt o takim na tym forum nie słyszał.

    Cytat:
    A jak piszesz np. funkcję podkolorowującą bitmapę, gdzie aż się prosi uzycie nasyceń to nie zwracasz uwagi na assembler? :]
    Albo jak piszesz w ISRrze PIDa do np. jakiejś przetwornicy to też nie?...
    Kompilatory przecież nie wykorzystują WSZYSTKICH ficzerów rdzeni...

    Ale przecież ARM7 czy Cortex-M3 wcale nie mają jakichś cudownych i bardzo potrzebnych ficzerów, których kompilator nie potrafiłby użyć. W życiu nie napisałem żadnej funkcji dla ARMa w całości w assemblerze (pomijam startupy [; ), kompilator zrobi to na pewno lepiej. A jak już wykorzystam czasem (rzadko) wstawki, to do rzeczy które dosyć ciężko zrobić wydajnie w C (rbit, clz, rev, ...). Bez tych wstawek też bym przeżył...

    Cytat:
    Do CM3 jest errata :P No poza tym nie jest to już absolutna nowość - procki na tym rdzeniu istnieją już od paru lat. A jeśli chodzi o ludzi "znających się" - gdzie odczuwasz brak takich ludzi?

    elektroda to nie cały świat, poza tym wychodzi mi tak z czystej logiki. Jeśli ARM7 jest na rynku X lat, a Cortex-M3 X/3 lat, to wiadomo, że ludzi wiedzących coś o ARM7 będzie więcej.

    Cytat:
    BTW, skoro ARM7 nadal ma tyle zalet i - jak twierdzisz - są bardziej dopracowane, i lepszy support, itp itd, to czemu pracujesz z CM3?...

    Przekornie zależy mi na tym, żeby nie wyrzucać od razu ARM7 do kosza, bo one i tak są milion lat świetlnych przed AVRami, PICami czy '51. Poza tym nikt nie pytał o moje prywatne preferencje (; Zresztą nie wykluczam przecież że kiedyś zrobię coś na ARM7 jak akurat będzie mi pasował bardziej. Np super kontroler LCD wciąż najlepszy będzie na LPC2478, bo LPC18xx (Cortex-M3@150MHz z [zależnie od modelu] kontrolerem LCD) jeszcze nie jest dostępny i pewnie wcale tak szybko nie będzie go można kupić.

    4\/3!!

    0
  • #10 21 Paź 2010 17:33
    PietrekDer
    Poziom 13  

    Hmm, widzę że wywołałem małą burzę wśród osób sympatyzujących z rdzeniami Cortex a ARM. W każdym bądź razie dziękuję wszystkim którzy się wypowiadają w tym temacie, bo każda informacja jest przydatna. :)

    0
  • #11 21 Paź 2010 18:27
    nsvinc
    Poziom 35  

    tymon_x napisał:
    [...]VIC było mi trudniej okiełznać niż NVIC[...]

    Hm, chyba nie zrozumiales o co chodzi...Porownanie dotyczylo ISRow pisanych gdy (N)VIC istnieje, vs. brak jakiegokolwiek VIC...

    Freddie Chopin napisał:
    A jak już wykorzystam czasem (rzadko) wstawki, to do rzeczy które dosyć ciężko zrobić wydajnie w C (rbit, clz, rev, ...). Bez tych wstawek też bym przeżył...

    Kazdy by przezyl bez wstawek. Ale podam przyklad z zycia wziety: funkcja podkolorowujaca obrazek pixel po pixlu. Kompilator keila(-o3) wygenerowal ok. 25 instrukcji, ja piszac w asmie z wykorzystaniem usat zamknalem sie w kilkunastu.
    Drugim, lepszym przykladem jest funkcja wyswietlajaca znak z charmapy:
    Code:

    __asm u16 lcdchr(u16 x,u16 y,u16 c,u8 d)
    {
       PUSH {r4-r7}
       LDR r4, =__cpp(charmap)
       MOV r5, #12
       MLA r3, r3, r5, r4 //r3=charmap+d
       //experiment
       LDR r5, [r3]
       LDR r6, [r3, #4]
       ORR r6, r5, r6
       LDR r5, [r3, #8]
       ORR r6, r5, r6
       UBFX r5, r6, #16, #16
       ORR r6, r5, r6
       UBFX r5, r6, #8, #8
       ORR r4, r5, r6
       //!experiment
       MOV r5, #7
       RBIT r4, r4
       CLZ r4, r4
       SUBS r4, r5, r4 //w r4 =dlugosc znaku, r5 jest wolny
       ITTT MI
       MOVMI r0, #0
       POPMI {r4-r7}
       BXMI lr    //return w ifie....
       MOV r6, #640
       LDR r7, =__cpp(PIP2ADDR)
       LSL r0, r0, #1
       ADD r0, r7, r0
       MLA r6, r1, r6, r0
       MOV r1, #7040
       ADD r6, r6, r1 //w r6 jest adres pierwszego piksla w ostatniej linji, r5,r7 wolny
       MOV r7, #11
       ADD r0, r4, #1
    linja
          LDRB r5, [r3, r7] //r5=pierwszy bajt znaku z charmapy   
          LSL r5, r5, #24
          ADDS r5, r5, r5
          IT SH
          STRCSH r2, [r6]
          ADDS r5, r5, r5
          IT SH
          STRCSH r2, [r6, #2]
          ADDS r5, r5, r5
          IT SH
          STRCSH r2, [r6, #4]
          ADDS r5, r5, r5
          IT SH
          STRCSH r2, [r6, #6]
          ADDS r5, r5, r5
          IT SH
          STRCSH r2, [r6, #8]
          ADDS r5, r5, r5
          IT SH
          STRCSH r2, [r6, #10]
          ADDS r5, r5, r5
          IT SH
          STRCSH r2, [r6, #12]
          ADDS r5, r5, r5
          IT SH
          STRCSH r2, [r6, #14]
          SUB r6, r6, #640
          SUBS r7, r7, #1
          BPL linja   
       POP {r4-r7}   
       BX lr
    }

    Kompilator wygenerowal ta funkcje w ponad 100 instrukcji (bez rozwijania petli)... asm ma moc wiec jednak warto zwracac na to uwage...

    Freddie Chopin napisał:
    Jeśli ARM7 jest na rynku X lat, a Cortex-M3 X/3 lat, to wiadomo, że ludzi wiedzących coś o ARM7 będzie więcej.

    A 8051 jest na rynku 3x lat. Za np. 5 lat wcale nie bedzie go znac wiecej ludzi niz teraz, a nawet znacznie mniej. Z czasem jedne procki sa zastepowane innymi, lepszymi. Skoro istnieje "lepszy" CM3, to po co brac sie za starszy i gorszy ARM7?

    Freddie Chopin napisał:
    [...]LPC18xx (Cortex-M3(małpa)150MHz z [zależnie od modelu] kontrolerem LCD)[...]

    Probki juz u mnie gdzies w chacie leza, niestety bez flasha. Wersje z flashem maja wejsc do sprzedazy w 1 kwartale 2011...

    0
  • #12 21 Paź 2010 18:35
    Freddie Chopin
    Specjalista - Mikrokontrolery

    nsvinc napisał:
    A 8051 jest na rynku 3x lat. Za np. 5 lat wcale nie bedzie go znac wiecej ludzi niz teraz, a nawet znacznie mniej. Z czasem jedne procki sa zastepowane innymi, lepszymi. Skoro istnieje "lepszy" CM3, to po co brac sie za starszy i gorszy ARM7?

    Po pierwsze moim zdaniem mylisz się, bo o '51 wiem coś nawet ja, znam też pełno osób, które wiedzą dużo o '51, a nie wiedzą nic o ARMach (poza tym że istnieją).
    Po drugie skoro jesteś tak bardzo za nowościami, to przecież są jeszcze nowocześniejsze i wydajniejsze rozwiązania niż Cortex-M3, np AVR32, który ponoć jest nawet tańszy. Jeśli zaś wydajność ARM7 jest zbyt mała, to może zamiast Cortex-M3 od razu zacząć od Cortex-A9 albo choć ARM11? Co powiesz w kwestii kiepskiej wydajności kodu odpalanego z RAMu na Cortexach, które głęboko pod spodem mają dwie osobne szyny, a nie jedną bardzo szybką jak ARM7?

    itd.

    Zaś co do twoich optymalizacji assemblerowych, to skoro flashem się nie przejmujesz, to po co podajesz ilość instrukcji, która jak wiadomo ma się nijak do szybkości wykonywania kodu? To że napisałeś funkcję krótszą o 100 bajtów nie jest specjalnie poruszające - więcej można zyskać o wiele mniejszym kosztem, poza tym na maxymalnej optymalizacji rozmiar kodu jest na ostatnim miejscu dla kompilatora. Porównaj prędkość, wtedy może okazać się, że (np.) 2 dni spędziłeś nad tym, żeby program działał (np.) 3% szybciej, choć i tak przez (np.) 80% czasu (jak to większość programów) nic nie robi... Gorzej jeśli działa nawet wolniej... Pomijam oczywiste oczywistości typu trudności ze zrozumieniem, zmianą czy poprawieniem tego kodu czy przeniesieniem go na inny rdzeń.

    4\/3!!

    0
  • #13 21 Paź 2010 19:19
    nsvinc
    Poziom 35  

    Freddie Chopin napisał:
    Po pierwsze moim zdaniem mylisz się, bo o '51 wiem coś nawet ja, znam też pełno osób, które wiedzą dużo o '51, a nie wiedzą nic o ARMach (poza tym że istnieją).

    Może to wina DSM-51 i to, że uczą tego na studiach?...:]

    Freddie Chopin napisał:
    Po drugie skoro jesteś tak bardzo za nowościami, to przecież są jeszcze nowocześniejsze i wydajniejsze rozwiązania niż Cortex-M3, np AVR32, który ponoć jest nawet tańszy.

    Hm, te "nowości" to jeszcze muszą być dobrze dostępne do produkcji masowej. Polityka Atmela odstrasza. Poza tym, zestaw instrukcji AVR32 nie jest taki miły jak jakikolwiek zestaw rdzeni ARM.

    Freddie Chopin napisał:
    Jeśli zaś wydajność ARM7 jest zbyt mała, to może zamiast Cortex-M3 od razu zacząć od Cortex-A9 albo choć ARM11?

    Gdyby to jeszcze były mikrokontrolery to jak najbardziej bym zaczął je stosować tu, gdzie jest jakiś większy LCD-TFT do obsłużenia. Ja się już namęczyłem z LPC3250 i mam dosyć mikroprocesorów...

    Freddie Chopin napisał:
    Co powiesz w kwestii kiepskiej wydajności kodu odpalanego z RAMu na Cortexach, które głęboko pod spodem mają dwie osobne szyny, a nie jedną bardzo szybką jak ARM7?

    CM3 jest dedykowany pod aplikacje typowo mikrokontrolerowe - czyli kod będzie się w 99% przypadków wykonywał z flasha - no i pod to rdzen został zoptymalizowany. Wydajność wykonywania kodu z RAMu też nie jest taka tragiczna - przerabiałem freeRTOSa tak aby odpalał niezależne "programy" (brane skądkolwiek, np. karta SD) jako wątki - właśnie z RAMu, i nie było bolesnego spadku wydajności gdy porownane zostały dwa identyczne wątki - jeden z flasha, drugi z RAMu.
    Poza tym, jak bardzo szybsza jest magsistrala w ARM7? Na pewno nie szybsza niż sam rdzen....

    Freddie Chopin napisał:
    Porównaj prędkość, wtedy może okazać się, że (np.) 2 dni spędziłeś nad tym, żeby program działał (np.) 3% szybciej, choć i tak przez (np.) 80% czasu (jak to większość programów) nic nie robi...

    W ogóle nie chodzi o rozmiar kodu :]
    W tej aplikacji procesor ma co robić. Oczywiście te wypociny w asmie były benchmarkowane, i widać, że chodzi to znacznie szybciej niż to, co wygenerował kompilator (benchmark w postaci rzucanego po wyświetlaczu tekstu). Ogólnie zamysł był taki, żeby na test (na TP) gładko przewijać pełny wyświetlacz tekstu...
    Swoją drogą, jak coś się ma wykonywać np. 50k razy na sekundę, a pisząc w asmie tą funkcję zaoszczędzisz np. 10cykli, to już procek ma 500k cykli na coś innego.
    Faktycznie, gdy kod ma się wykonywać raz na ruski rok, to może trwać ilekolwiek, no i wtedy szkoda zachodu. Ale warto na pewno optymalizować często występujące przerwania i choćby takie funkcje pracujące na grafice.

    0
  • #14 22 Paź 2010 09:25
    genzi
    Poziom 9  

    Witam,

    miałem do czynienia z LPC2148 z rdzeniem ARM7 i z LPC1768 z rdzeniem Cortex-M3. Moim zdaniem rdzeń Cortex jest bardziej przemyślany od ARM7. Oba typy procesorów zaczynałem programować od razu w C i nie zagłębiałem się w ich dokładną budowę. Przed napisaniem pierwszego programu polecam jednak, żeby chociaż ogólnie zorientować się w budowie uC. Jeśli pisze się programy które robią coś więcej niż tylko miganie diodą, to trzeba po kolei dokładnie poznać cały rdzeń i wszystkie peryferia. Chociażby dlatego, że w pewnym momencie coś nie działa i nie wiadomo dlaczego.
    To prawda że do Cortex'ów jest dużo mniej literatury ale jeśli ma już się jakieś pojęcie o programowaniu uC, to dokumentacja i przykłady powinny w zupełności wystarczyć. Ogólnie polecam rdzeń Cortex, ale trzeba uważać na LPC z serii 17xx bo jest problem z RTC który nie zawsze działa. Na stronie NXP są opublikowane erraty odnośnie tego problemu. Z tego co się orientuję poprawione procesory mają się pojawić pod koniec roku.

    Pozdrawiam

    0