Mam zamiar przesiąść się z AVR na ARM9, jednak coś trudno mi wystartować.
Mam development board (FriendlyARM) z przykładami kodu (interesuje mnie
programowanie bez OS), ale nie potrafię tego skompilować. Podpowiedzcie,
gdzie znaleźć jakieś kompletne "hello world", chocby i miganie LED-em,
ale kompletny projekt pod gcc. A najlepszy byłby oczywiście jakiś tutorial.
Do AVR pełno tego, a do ARM-a nic nie mogę znaleźć :/

Pozdrawiam,
Dariusz Żołna

do góry

Dariusz Zolna pisze:

> Do AVR pełno tego, a do ARM-a nic nie mogę znaleźć :/

http://www.freddiechopin.info/index.php/pl/artykuly/
35-arm/59-arm-toolchain-tutorial

do góry

Dariusz Zolna wrote:

> Mam zamiar przesiąść się z AVR na ARM9, jednak coś trudno mi wystartować.
> Mam development board (FriendlyARM) z przykładami kodu (interesuje mnie
> programowanie bez OS), ale nie potrafię tego skompilować.

> Podpowiedzcie, gdzie znaleźć jakieś kompletne "hello world", chocby i
> miganie LED-em, ale kompletny projekt pod gcc. A najlepszy byłby
> oczywiście jakiś tutorial. Do AVR pełno tego, a do ARM-a nic nie mogę
> znaleźć :/
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.

---> http://www.friendlyarm.net/dl.php?file=linux-example
s.tgz
i 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;
}

do góry

cepu69 pisze:
> A czy zastanowiles sie nad przyczyna takiego stanu rzeczy???

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


> 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.
>
> ---> http://www.friendlyarm.net/dl.php?file=linux-example
s.tgz
> i 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;
> }
>

do góry

On 16.02.2010 16:33, Dariusz Zolna wrote:
> cepu69 pisze:
>> A czy zastanowiles sie nad przyczyna takiego stanu rzeczy???
>
> Tak, zastanawiałem się i nie potrzebuję systemu. Dlatego właśnie
> wybrałem Mini2440 a nie EPIĘ PX.

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?

...
> 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'
...

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


Pozdrawiam,
--
Artur Lipowski

do góry

Dariusz Zolna wrote:

> cepu69 pisze:
>> A czy zastanowiles sie nad przyczyna takiego stanu rzeczy???
>
> Tak, zastanawiałem się i nie potrzebuję systemu. Dlatego właśnie
> wybrałem Mini2440 a nie EPIĘ PX.
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.

> 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.
Nie wiem o jakich przykladach mowisz bo wszystko co linuch-podobne czyli
loader : u-boot itp oraz linuchy sa TYLKO kompilowalne z uzyciem 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.
Ja osobiscie nie rzezbil bym w wynajdowanie kola, tylko uzyl ktoregos z
bootloaderow jako projekt bazowy bo dzial na tej platformie :
-> http://www.friendlyarm.net/dl.php?file=bootloader_20
090728.zip
vboot 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

do góry

Artur Lipowski pisze:
> 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?

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.


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

Prawie 900 linii :/

Dariusz Żołna

do góry

Dariusz Zolna wrote:

> Artur Lipowski pisze:
>> 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?
>
> 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.
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.

> Nie uważam, żeby ARM9 był dużo bardziej kłopotliwy w programowaniu niż
> Atmega128, na którą mam kilkadziesiąt tys linii kodu.
Dokladnie i dlatego tez mozna samemu oprogramowac wersje embbeded x86 -
wywalasz BIOS'a i startujesz swoj kod zaraz po resecie ;)

>> Bo pewnie plik jest napisany asemblerem według składni ARM-a.
>> Zmiana języka na wariant GNU prosta, acz uperdliwa.
>
> Prawie 900 linii :/
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 -> http://sourceware.org/newlib/
a driver, czyli dostep do portu szeregowego napisal sam.

do góry

cepu69 pisze:
> 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 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ół.


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

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

do góry

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

>> Jaki to może być projekt, który wymga takiego "potwora" jak ARM9, a
>> nie wymaga systemu?
>
> 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.

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).

> Nie uważam, żeby ARM9 był dużo bardziej kłopotliwy w programowaniu niż
> Atmega128, na którą mam kilkadziesiąt tys linii kodu.

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 (www.ethernut.de). 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?

--
Adam Dybkowski
http://dybkowski.net/

Uwaga: przed wysłaniem do mnie maila usuń cyfry z adresu.

do góry