Planuję migrację do architektury NXP Cortex M3 i jestem trochę zagubiony między istniejącymi narzędziami programistycznymi.
Keil jest drogi i nie wiem, czy warto. Każdy, kto próbował jakiegoś kompilatora, może udzielić porady?
Znalazłem ten kompilator http://www.code-red-tech.com/red-suite-2.php, który wydaje się dobry i niedrogi. Ktoś, kto próbował lub wiedział o tym, może dać mi więcej informacji?
Odpowiedzi:
W wolnym czasie gram ze STM32 (także Cortex M3) i korzystam z dystrybucji CodeSourcery GCC, która całkiem dobrze się sprawdziła.
Kolega, który w przeszłości profesjonalnie pracował z mikroprocesorami ARM, powiedział mi, że jest zadowolony z zestawu narzędzi IAR, chociaż nie wiem, jaki jest koszt i jakie jest wsparcie dla Cortex.
źródło
Korzystam z kompilatorów krzyżowych CodeSourcery (Lite) dla systemu Linux do programowania mikrokontrolerów TI Stellaris . Działają z dowolnym Cortex-M3. Są całkowicie bezpłatne, z plikami binarnymi dla systemu Windows i Linux.
Oto krótki przepis (Debian / Ubuntu) do zainstalowania:
Pobierz zestaw narzędzi (wystarczy dowolna wersja, ale używam tego)
Zainstaluj środowisko Java Runtime Environment (dla przeklętego instalatora)
zainstalować
Dodaj katalog bin kompilatora między ścieżkami do PATH
Do załadowania kodu i debugowania potrzebujesz OpenOCD i gdb lub jednego z GUI.
Będziesz także potrzebował adaptera JTAG .
źródło
Zacząłem używać jednego z nich (płyta programisty MBED). Dużą zaletą dla mnie było to, że mogłem kodować w C lub C ++, proste połączenie z USB i sprytne środowisko programistyczne online (wcale nie jest wymagana instalacja lokalnego narzędzia!).
http://mbed.org/
Pięć minut po otwarciu pudełka miałem przykładowy mrugający program („witaj świecie” w świecie, który się pojawił) z następującymi programami:
To jest to! Powyżej znajduje się pełny program!
Opiera się na ARM Cortex M3, szybkiej i dużej ilości pamięci dla projektów osadzonych (100 MHz, 256k flash i 32k RAM). Internetowe narzędzia programistyczne mają bardzo dobrą bibliotekę i wiele przykładów oraz bardzo aktywne forum. Dużo pomocy w podłączaniu urządzeń do MBED itp
Mimo że mam duże doświadczenie z systemami wbudowanymi (ARM 7/9, Renases M8 / 16/32, Coldfire, Zilog, PIC itp.), Wciąż uważam, że jest to bardzo łatwy w obsłudze system, z którym mogę sobie poradzić, mając jednocześnie poważne możliwości.
Po początkowej zabawie z podstawową płytką ścienną kupiłem płytę podstawową od tych facetów: http://www.embeddedartists.com/products/lpcxpresso/xpr_base.php?PHPSESSID=lj20urpsh9isa0c8ddcfmmn207. To ma stos urządzeń I / O (w tym miniture OLED i 3-osiowy akcelerometr). Z tej samej strony kupiłem także jedną z płyt procesorowych LCPExpresso, która jest tania, mniej energii / pamięci niż MBED, ale idealna do mniejszych zadań (wciąż hamuje bzdury procesorów PIC / Atmega). Płyta główna obsługuje zarówno LCPExpresso, jak i MBED. Kupując płytę procesorową LCPExpress, dostałem też dołączony debugger JTAG i środowisko deweloperskie offline (zestaw deweloperski oparty na GCC / Eclipse firmy Code Red). Jest to o wiele bardziej skomplikowane niż internetowe środowisko programistyczne MBED, ale jest logicznym postępem po zdobyciu doświadczenia w korzystaniu z MBED.
Odnosząc się do mojego pierwotnego punktu, no no, że kontroler MBED jest znacznie bardziej wydajny niż kontroler LPCExpresso, ALE jest o wiele prostszy w użyciu i nauce.
źródło
kod źródłowy lite jest dobry lub użyj emdebian. lub stwórz własną, jest to dość łatwe, chyba że potrzebujesz pełnej biblioteki C lub gcc, to nadal jest wykonalne, ale trochę trudniejsze. na początku nie będziesz potrzebować kompilatora obsługującego thumb2, thumb zrobi to, gdy będziesz szukać łańcucha narzędzi, który ci się podoba.
lvv jest kolejnym dobrym (użyj clang, a nie llvm-gcc !!), wiem, że strona ramienia jest coraz lepsza, wersja 27 produkowała szybszy kod niż bieżący gcc dla konkretnego testu. Znalazłem błąd po stronie kciuka podczas pracy z emulatorem kciuka (thumbulator.blogspot.com), który został natychmiast naprawiony. Najlepsze w llvm jest to, że domyślnie jest to kompilator krzyżowy, nie wymaga dodatkowej pracy ani doświadczenia w budowaniu. W ciągu następnych kilku lat widzę, jak wnikają głębiej w gcc i przekazują gcc do kompilacji krzyżowej / osadzania.
Próbowałem raz narzędzie z kodem czerwonym na płycie lpcxpresso, końcowy wynik jest taki, że zdecydowanie nigdy nie używam kodu z kodem i zastanawiam się, czy też nie umieścić na czarnej liście lpc. ymmv. Jeśli musisz użyć narzędzia do płacenia, wybrałbym keil tylko dlatego, że zostały zakupione ręcznie, a częścią pakietu jest kompilator rvct. Oczywiście kodu źródłowego jest również domem odpłatnym, jeśli nie spełniasz limitów lite lub zdecydujesz się uzyskać wsparcie, ponieważ gcc ma najlepsze wsparcie ze wszystkich kompilatorów. Nie tak dawno temu, kiedy mogłem wypróbować je metaware, a narzędzia ramienia zdmuchnęły gcc aż do jakości wytworzonego kodu. gcc jest w górę i na dół niektóre wersje 3.x produkują lepszy kod niż 4.x, nie wydają się poprawiać w każdym wydaniu, ale niedawno dodały obsługę thumb2, co nie jest możliwe w wersjach 3.x / nie będzie.
źródło
If you have to use a pay for tool I would go with keil only because they were bought by arm
- Czy próbowałeś kompilatorów Keil? Przynajmniej nie byłem pod wrażeniem narzędzi Keil 8051. Czują się jak dinozaury w porównaniu z konkurencją opartą na GCC lub pakietem LLVM / Clang, IMHO.Używam oprogramowania Rowley do programowania ARM i MSP430:
http://www.rowley.co.uk
To jest świetne. Cortex-M3 jest obsługiwany.
źródło
Używam debugera Yagarto + Eclipse + J-link edu. (Łańcuch narzędzi GNU)
http://www.yagarto.de/
źródło
Miałem całkiem niezły sukces przy użyciu kompilatora / łańcuchów debugowania IAR do mojego rozwoju ARM. Oferują one stosunkowo stabilne narzędzia programistyczne wraz ze środowiskiem Embedded C ++ (co wydaje się dość rzadkie). - W zależności od rozmiaru bazy kodu, oferują również świetne oprogramowanie / zestawy „KickStart Kits” z ograniczonymi rozmiarami wersji swoich narzędzi.
źródło
IAR jest doskonały, a jeśli wykonujesz małe projekty, dostępna jest bezpłatna edycja kickstart w rozmiarze 32K. Uaktualnienia rozmiaru są jednak nieco drogie. Są również wyposażone w mnóstwo dobrych przykładowych projektów, zwykle kilka dla każdej rodziny procesorów.
źródło
Ostatnie kilka dni spędziłem na kompletnym skonfigurowaniu zestawu narzędzi CodeSourcery GNU dla EFM32G micro na OS X. Warto było. W porównaniu z wieloma debuggerami opartymi na GUI, których próbowałem (głównie w środowisku Eclipse); Makefiles, GCC i GDB to spełnienie marzeń; plus wszystko działa z mojego terminala Linux lub Mac.
Jedyne, co jest do bani, to adapter J-Link wbudowany w płytkę. Program GDBServer dla systemu Windows i Linux J-Link jest zamkniętym źródłem. Co gorsza, wersja Linux jest DUŻO za nią. Aby GDB działał, muszę uruchomić obraz Windows VMWare, którego jedynym celem jest uruchomienie GDBServer (ponieważ Linux jest zepsuty).
Poza tym, nie działając poprawnie, oparty na Linuksie serwer GDB J-Link łączy się z 127.0.0.1 i nasłuchuje TYLKO pakietów z tym jako dest; więc potrzebne są bałagany w iptables i przekazywanie, aby połączyć się ze zdalną maszyną. Śmieszny; Segger musi zebrać się w sobie.
źródło
Używam QtCreator i GNU Tools ARM Embedded. Działa dobrze.
Zalety:
Niedogodności:
Gdy wszystko jest poprawnie skonfigurowane, mogę kliknąć, aby utworzyć punkt przerwania w moim kodzie, a następnie kliknąć przycisk „debuguj”. Kompiluje, flashuje, wykonuje i zatrzymuje się na punkcie przerwania za około 5 sekund (i jednocześnie wywołuje wściekłość, jeśli kiedykolwiek będziesz musiał wrócić do Arduino „IDE”).
Pracuję nad samouczkiem, w jaki sposób skonfigurować to z innym układem ARM - nRF51822 na bazie Cortex-M0.
źródło
Używam narzędzi CooCox, jest doskonały, ale darmowy, nie ma ograniczenia rozmiaru kodu. http://www.coocox.org/
źródło
Używam arm-eabi-gcc i dołączonego do niego zestawu narzędzi za pomocą skryptu przywołania zestawu narzędzi arm . Skrypt konfiguruje środowisko do wykonywania pracy bez systemu operacyjnego na ARM. Jest to darmowy i otwarty program, a wszystko to działało dla mnie niezawodnie. Użyłem do tego również IAR, i na pewno jest to lepsze, ponieważ pozwala ci robić dużo bardziej przyjazne debugowanie i robić rzeczy w sposób IDE, ale ogólnie czuję się bardziej komfortowo z gcc, jeśli nie z innego powodu, ponieważ ja nie musisz nikomu uzasadniać wydatków.
(Nigdy tak naprawdę nie nauczyłem się używać gdb do niczego, ale tak naprawdę nigdy nie byłem przyzwyczajony do używania debuggera lub posiadania go, więc nie jestem pewien, czy mam kwalifikacje, aby oceniać ten kawałek.)
źródło
Używam Emprog ThunderBench . Jest doskonały, prawdopodobnie najlepszy, jaki kiedykolwiek użyłem.
Najbardziej podoba mi się to, że jest to jednocześnie kompilator kory C / C ++ ARM , debugger i IDE.
źródło