kompilatory do ARMów

Keila używam do ARMow i musze powiedzieć, że jest ok. Keil jest dosyć popularny, dzięki czemu jak kompilator wyrzuca jakiś dziwny error czy warning to jest duża szansa, że na necie znajdziesz opis jak go się pozbyć. Ma też zestaw przykładów dzięki czemu łatwo zacząć pisać programy. IAR używałem do MSP430 i był raczej średni. Ma tą wadę, że symulator nie symuluje pracy peryferiów (w keilu tak), ale jak się ma JTAGa to jest to mniej istotne. Według mnie Keil jest łatwiejszy w obsłudze do IAR.

pozdrawiam tn

RoBert pisze:

Jeżeli chodzi Ci o _kompilator_ to jakiej od niego wymagasz "łatwości w obsłudze" (wszystko załatwiają wszakże pliki makefile) oraz "przydatnych funkcji". Do ARMów polecam gcc, np. w postaci pakietu gnuarm.

Adam Dybkowski snipped-for-privacy@45wp.pl napisał(a):

Z tego samego gatunku (GNU) jest jeszcze pakiet WinARM. Wszystko w nim jest skompilowane bezpośrednio pod Windows więc nie wymaga do pracy Cygwin. W pakiecie stado przykładów na uC LPC Philipsa.

Posraldescu pisze:

Jeżeli sam dłubiesz pod Windozą to OK. Ale jeżeli nad projektem pracuje równolegle kilka osób pod Win i Linuxem a potrzebują do tego w miarę spójnego środowiska - to gnuarm jest jak znalazł. Co nie zmienia faktu, że niestety gnuarm (gcc 3.4.3) pod Linuxem daje inne wyniki kompilacji niż pod Win - przy identycznym makefile jakoś linker w innej kolejności dołącza biblioteki. Kaszana.

Adam Dybkowski snipped-for-privacy@45wp.pl napisał(a):

Jesteś pewny, że za kompilacje odpowiada identyczna wersja make. Przecież jest możliwa sytuacja, że make w obu przypadkach jest inne. U mnie za sterowanie kompilacją firmowego środowiska pod RISC odpowiada make zapożyczony z OpenWatcom.

Posraldescu przemówił ludzkim głosem:

To ja dodam jeszcze pakiet od codesourcery. ARM płaci tej firmie za rozwijanie portu gcc pod arm, więc w ich paczkach najwcześniej znajdziesz poprawki, optymalizacje, czy obsługę nowych architektur (tak było z corteksem).

In the darkest hour on Tue, 18 Nov 2008 00:39:59 +0100, Adam Dybkowski snipped-for-privacy@45wp.pl screamed:

A na jakimś nowszym gcc? Tak samo?

Posraldescu pisze:

Make chyba tu nie ma nic do rzeczy, bo tylko steruje wywołaniem innych narzędzi. Porównywaliśmy w firmie wyniki kompilacji identyczną wersją gcc (3.4.3) z pakietu gnuarm odpalonego pod WinXp i OpenSuse. Prawie wszystko wychodzi identycznie, znaczące różnice są dopiero na etapie linkowania. make -n pokazuje dokładnie te same parametry wywołania linkera (w tym kolejność bibliotek, ścieżek itp) na obu platformach ale w wynikowym pliku .elf (i widać to też w .map) funkcje wyciągane z bibliotek są umieszczane w sekcji .text w różnej kolejności. Oczywiście nie ma to wpływu na samo działanie skompilowanego programu (na AT91SAM9261) ale daje inną jego postać binarną (co pociąga za sobą inny skrót z binariów, co jest w naszym przypadku ważne).

Artur M. Piwko pisze:

Od pewnego czasu nie wychodzą nowsze pakiety gnuarm na stare procki x86 (nie 64-bitowe; o dziwo dla Windows są nowsze gnuarm'y) więc się oficjalnie w firmie nie przesiadamy. Samodzielnie skompilować gcc nikomu się nie chce / nie ma na to czasu.

nie jest to kwestia sortowania katalogow plikow [directory] przez oba systemy przy odczycie ich zawartosci, ewentualnie malych i duzych liter w nazwach plikow ?

J.

J.F. pisze:

Wielkość liter jest ta sama, rzeczywiście może chodzić o sortowanie czy wręcz kolejność umieszczenia plików w katalogu przy ich kreacji (ściąganiu z repozytorium CVS). Sprawdziliśmy w każdym razie, że kilka komputerów używających tej samej wersji Windows XP, cygwina oraz gnuarm, daje dokładnie te same wyniki binarne po zlinkowaniu całości projektu. A Linux niech spada na bambus. ;)

Ale moze inaczej wplywac na sortowanie w roznych systemach.

J.

J.F. pisze:

AFAIK jeżeli robisz opendir/readdir/closedir to sortowania nie ma. Funkcja readdir zwraca informacje o plikach w kolejności ich zapisania w katalogu (czyli wg własnego widzimisię konkretnego systemu plików). Sortowanie jest robione w samym programie ls / mc itp.