ARM9 + GCC + makefile do hello world

Dariusz Zolna pisze:

A czy zastanowiles sie nad przyczyna takiego stanu rzeczy???

To jest juz procesor (CPU: 400 MHz Samsung S3C2440A ARM920) a nie kontroler i naprawde malo kto bawi sie bez OS-a.

Naprwade nie warto - jesli masz port systemu na dana platforme to migniecie diodami wymaga 5 minut pracy.

--->

przyklad leds :

int main(int argc, char **argv) { int on; int led_no; int fd; if (argc != 3 || sscanf(argv[1], "%d", &led_no) != 1 || sscanf(argv[2],"%d", &on) != 1 || on < 0 || on > 1 || led_no < 0 || led_no > 3) { fprintf(stderr, "Usage: leds led_no 0|1\n"); exit(1); } fd = open("/dev/leds0", 0); if (fd < 0) { fd = open("/dev/leds", 0); } if (fd < 0) { perror("open device leds"); exit(1); } ioctl(fd, on, led_no); close(fd); return 0; }

cepu69 pisze:

Tak, zastanawiałem się i nie potrzebuję systemu. Dlatego właśnie wybrałem Mini2440 a nie EPIĘ PX.

Na friendlyarm jest zestaw testowych funkcji, które nie wyglądają na wielce skomplikowane (mam o wiele bardziej rozbudowane projekty na AVR). Problemem jest to, że chińczyki przygotowały je przy użyciu komercyjnego kompilatora, a ja jednak wolałbym użyć GCC.

Zrobiłem pewien postęp, projekt się kompiluje, ale kompilator nie lubi pliku "2440init.s". Wygląda jakby traktował go jako plik w C a nie w Asemblerze.

Zgodnie z "tutorialem" podsuniętym przez Kris_gor używam GCC (Sourcery) i Eclipse.

Ktoś ma jakieś sugestie jak poprawnie włączyć ten plik w asemblerze do projektu? Kompilator dostaje go chyba z poprawnymi flagami:

arm-none-eabi-gcc -x assembler-with-cpp -c -mcpu=arm920t -mthumb -g

-ggdb3 -Wa,-amhls=./out/2440init.lst -MD -MP -MF ./out/2440init.d -I . 2440init.s -o out/2440init.o

więc może to kwestia poprawności zapisu samego kodu? Bo dostaję mnóstwo błędów typu:

2440init.s:13: Error: bad instruction `get option.inc'

albo

2440init.s:30: Error: junk at end of line, first unrecognized character is `0'

Pozdrawiam, Dariusz Żołna

Tak z ciekawości (i bez złośliwości ;-) ). Jaki to może być projekt, który wymga takiego "potwora" jak ARM9, a nie wymaga systemu?

...

...

Bo pewnie plik jest napisany asemblerem według składni ARM-a. Zmiana języka na wariant GNU prosta, acz uperdliwa.

Pozdrawiam,

Upps, aler moja sugestia zmierzla w kierunku iz rzeczony ARM jest odpowiednikiem platformy x86 czyli juz lekko skomplikowany czyli nie wart wynajdowania kola od nowa.

Nie wiem o jakich przykladach mowisz bo wszystko co linuch-podobne czyli loader : u-boot itp oraz linuchy sa TYLKO kompilowalne z uzyciem gcc

Ja osobiscie nie rzezbil bym w wynajdowanie kola, tylko uzyl ktoregos z bootloaderow jako projekt bazowy bo dzial na tej platformie :

->

wyglada na najprostszy i o dziwo buduje sie go przy pomocy arm-linux-gcc ;) przynajmniej tak twierdzi Makefile ;)

all: arm-linux-gcc -mabi=aapcs-linux -mno-thumb-interwork -Os -Wall -c head.S 244x_lib.c nand.c main.c arm-linux-ld -T mem.lds -Bstatic head.o 244x_lib.o nand.o main.o arm-linux-objcopy -O binary -S a.out vboot.bin -R .comment -R .stab -R .stabstr rm *.o a.out

clean: rm vboot.bin

Artur Lipowski pisze:

Potrzebuję obsługiwać TFT 800x480, komunikować się ze światem zewnętrznym przez UART albo I2C, a nie potrzebuję całego narzutu zbędnych funkcji, startowych napisów, loga i kilkunastu sekund na uruchomienie systemu. Nie uważam, żeby ARM9 był dużo bardziej kłopotliwy w programowaniu niż Atmega128, na którą mam kilkadziesiąt tys linii kodu.

Prawie 900 linii :/

Dariusz Żołna

Przepraszam za zlosliwosc ale jest to kolejna systuacja kiedy wychodzi podejscie typu : "OS powoduje tylko zbedny narzut" Szkoda tylko iz gdy pojawia sie np. potrzeba dostepu do targetu przez siec TCP/IP lub wyswietlania okienek - natychmiast problem narzutu znika.

A napisy startowe, logi i "zbedne funkcje" i tak bedziesz musial wyprodukowac.

Dokladnie i dlatego tez mozna samemu oprogramowac wersje embbeded x86 - wywalasz BIOS'a i startujesz swoj kod zaraz po resecie ;)

Co do problemu - u mnie w pracy pacjent zawzial sie i tez "z palucha popchna" wiekszego ARM. A zrobil to tak - tzw. rozbiegowke czyli inicjalizacja procesora wzial od producenta procka i podlaczyl jako biblioteke standardowa uzyl newlib-a ->

driver, czyli dostep do portu szeregowego napisal sam.

cepu69 pisze:

Nie jest i uwierz mi, żadnego koła nie wynajduję. Problem rozwiązałem i wszystko czego potrzebowałem śmiga jak chciałem - obraz wygenerowany przez mój program pokazuje się natychmiast po włączeniu zasilania. Bez żadnych zbędnych pierdół.

No to jednak chyba wynalazłem koło, z tym że GCC sobie nie radzi z kodem w asemblerze (albo ja nie wiem jak to zrobić), po prostu kupię kompilator ARM-a i tyle.

Dariusz Żołna

W dniu 2010-02-16 20:01, Dariusz Zolna pisze:

Oj chyba jako "system" uznajesz tylko wynalazki pokroju Linuxa czy Win. Na procki tego typu system operacyjny jest prawie że niezbędny (zarządzanie pamięcią, gotowe sterowniki np. do UARTu czy LCD, komunikacja sieciowa itp) - ale nie ma nic wspólnego ze "startowym logiem". A sam start przeciętnego systemu na ARM9 (nie Linuxa) to sekunda, może nieco mniej. Poczytaj np. o Nut/OS albo FreeRTOS (oba darmowe, dostępne z pełnymi źródłami).

A jednak jest. Sterowniki bardziej skomplikowane (ot choćby obsługa UARTu), zarządzanie pamięcią dużo bardziej zagmatwane (ARM9 ma kesze instrukcji i danych oraz MMU), jeszcze bardziej przerwania i wyjątki.

Polecam rozpoczęcie zabawy najlepiej od systemu, który obsługuje i ATmegę128, i różne ARMy - Nut/OS

Posiada wiele gotowych sterowników (UARTy, stos TCP/IP itd) tak że będziesz mógł skupić się na wytworzeniu właściwego "mięska" zamiast głowić się jak przełączać kilka wątków samemu.

Jednakże ARM9 to duży potwór i najlepiej się czuje np. w Linuxie. Poszukaj, czy dla twojej płytki nie ma już jakiegoś gotowego Linuxa (np. OpenWRT) - skupisz się wtedy na programowaniu po prostu aplikacji linuxowej. A możliwe, że twój LCD będzie już obsługiwany jako FrameBuffer - dostęp z własnej aplikacji banalny. System z Flasha będzie wstawać z 5s - to chyba nie za długo?

I tak sie stanie - systemy embedded sa krojone na miare, zbedne elementy nalezy wyrzucic i program pokazuje sie po starcie.

Przepraszam ale wydaje mi sie, ze nie jestes jeszcze gotowy na przesiadke na wieksze procki, szczegolnie iz chcesz kozystac z narzedzi opensource-owych.

GCC dobrze sobie radzi z asemblerami praktycznie wiekszosci procesorow natomiast nie jest wstanie nic zrobic z wszelkiej masci dyrektywami innych kompilatorow.

Na marg> W dniu 2010-02-16 20:01, Dariusz Zolna pisze:

A ja tradycyjnie dorzuce "swoj" kamyczek czyli eCos ->

plyta referencyjna zaportowana do eCos to SMDK2410 ->

Adam Dybkowski pisze:

Przyjmuję argumenty aczkolwiek obsługę LCD i UART mam działającą, a to wszystko czego potrzebuję. Na szybko przejrzałem proponowane przez Was systemy i nie znalazłem gotowej dystrybucji na S3C2440, a dziubanie w cudzym kodzie zajmie mi chyba więcej niż dokończenie mojej aplikacji. To czego teraz szukam to sposobu na trwałe zainstalowanie programu we flashu, bo póki co uruchamiam go tylko z poziomu supervivi (taki bootloader z menu, czy jak chińczyki go nazywają - BIOS).

Pozdrawiam, Dariusz Żołna

"Wybor nalezy do Ciebie" Minister Zdrowia i Opieki Spolecznej ;)

Ale powtorze jak mantre - predzej czy pozniej bedziesz musial pogrzebac i skorzystac z cudzego kodu chyba, ze wszystko bedziesz pisal sam.

W przypadku u-boota takze vivi - obraz uruchamianego systemu/programu ladowany jest do flash skad mozna go wystartowac i nalezy porostu kozystac z dobrodziejstw bootloader vivi : lib/command.c :

/* * Define (basic) built-in commands */ #if 0

"help [{cmds}] -- Help about help?" "boot [{cmds}] - Booting linux kernel" "call <addr> <args> -- Execute binaries" "dump <addr> <length> -- Display (hex dump) a range of memory." "flash [{cmds}]-- Manage Flash memory" "info -- Display vivi information" "load [{cmds}] -- Load a file" "mem -- Show info about memory" "reset -- Reset the System" "param [eval|show|save [-n]|reset]" "part [ help | add | delete | show | reset ] -- MTD partition" "test -- Test items" #endif

W dniu 2010-02-19 12:14, William Bonawentura pisze:

Gdybyś olał tą Javę to nada się praktycznie dowolny (począwszy od Arduino + Ethernet Shield). Pytanie pozostaje np. jakiej wymagasz wydajności (dla uproszczenia powiedzmy w MIPS) albo jakiego zegara w MHz, ile wymagasz pamięci RAM a ile pamięci programu. Z tym że głupie "Hello LED" na AVR zajmuje kilkanaście bajtów, a na ARM9 kilka KB więc tu trzeba wziąć poprawkę.

Przykładowo ARM926EJ-S (AT91SAM9260) ma na pokładzie mmNet1002 z Propoxu. I wszystko co potrzebujesz też jest: SPI, Eth10/100, RS232 itd. Wbudowany Linux ale można odpalić cokolwiek innego. Tylko nie wiem, czy sensownie uciągnie Javę (procek 200MHz nie poraża wydajnością). mmNet1002 kosztuje ok. 200-250 zł.

Jeżeli jesteś fanem Javy to polecam dowolny procek, który uciągnie system Android. Czyli ARM9 minimum, preferowany ARM11 albo OMAP3x. Na przykład płytkę BeagleBoard (do której trzeba tylko dospawać gotowe "plecki" z Ethernetem). Dla samego Androida jest bardzo sensowne środowisko developerskie od Google (oparte na Eclipse), można też pisać fragmenty programów w języku C. BeagleBoard kosztuje AFAIR $150.