NOWY TEMAT
elektroda NewsGroups Forum Index - Elektronika Polska - Gdzie znaleźć kompletny projekt 'Hello World' na ARM9 z GCC i makefile?
Dariusz Zolna
Guest
Guest
Tue Feb 16, 2010 1:22 am
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
Kris_gor
Guest
Guest
Tue Feb 16, 2010 8:20 am
Dariusz Zolna pisze:
Quote:
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
cepu69
Guest
Guest
Tue Feb 16, 2010 1:17 pm
Dariusz Zolna wrote:
Quote:
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???
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-examples.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;
}
Dariusz Zolna
Guest
Guest
Tue Feb 16, 2010 4:33 pm
cepu69 pisze:
Quote:
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
Quote:
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-examples.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;
}
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-examples.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;
}
Artur Lipowski
Guest
Guest
Tue Feb 16, 2010 7:26 pm
On 16.02.2010 16:33, Dariusz Zolna wrote:
Quote:
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.
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?
....
Quote:
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 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
cepu69
Guest
Guest
Tue Feb 16, 2010 7:32 pm
Dariusz Zolna wrote:
Quote:
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
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.
Quote:
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
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
Quote:
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
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_20090728.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
Dariusz Zolna
Guest
Guest
Tue Feb 16, 2010 8:01 pm
Artur Lipowski pisze:
Quote:
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?
).
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.
Quote:
Bo pewnie plik jest napisany asemblerem według składni ARM-a.
Zmiana języka na wariant GNU prosta, acz uperdliwa.
Zmiana języka na wariant GNU prosta, acz uperdliwa.
Prawie 900 linii :/
Dariusz Żołna
cepu69
Guest
Guest
Wed Feb 17, 2010 12:53 pm
Dariusz Zolna wrote:
Quote:
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
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.
Quote:
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 -
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
Quote:
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
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.
Dariusz Zolna
Guest
Guest
Wed Feb 17, 2010 11:51 pm
cepu69 pisze:
Quote:
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.
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ół.
Quote:
Ja osobiscie nie rzezbil bym w wynajdowanie kola, tylko uzyl ktoregos z
bootloaderow jako projekt bazowy bo dzial na tej platformie :
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
Adam Dybkowski
Guest
Guest
Thu Feb 18, 2010 12:42 pm
W dniu 2010-02-16 20:01, Dariusz Zolna pisze:
Quote:
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 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).
Quote:
Nie uważam, żeby ARM9 był dużo bardziej kłopotliwy w programowaniu niż
Atmega128, na którą mam kilkadziesiąt tys linii kodu.
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.
cepu69
Guest
Guest
Thu Feb 18, 2010 2:19 pm
Dariusz Zolna wrote:
Quote:
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ół.
I tak sie stanie - systemy embedded sa krojone na miare, zbedne elementy
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ół.
I tak sie stanie - systemy embedded sa krojone na miare, zbedne elementy
nalezy wyrzucic i program pokazuje sie po starcie.
Quote:
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.
Przepraszam ale wydaje mi sie, ze nie jestes jeszcze gotowy na przesiadke na
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.
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 marginesie AS dostarcza takze nieprzenosne dyrektywy
http://en.wikipedia.org/wiki/GNU_Assembler
http://sourceware.org/binutils/docs-2.19/as/ )
Adam Dybkowski wrote:
Quote:
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.
(...). 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 ja tradycyjnie dorzuce "swoj" kamyczek czyli eCos -
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.
(...). 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 ja tradycyjnie dorzuce "swoj" kamyczek czyli eCos -
http://ecos.sourceware.org/
Najblizsz plyta referencyjna zaportowana do eCos to
SMDK2410 ->http://www.testech-elect.com/aiji/smdk2410.htm
Dariusz Zolna
Guest
Guest
Thu Feb 18, 2010 8:17 pm
Adam Dybkowski pisze:
Quote:
W dniu 2010-02-16 20:01, Dariusz Zolna pisze:
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.
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.
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
William Bonawentura
Guest
Guest
Fri Feb 19, 2010 12:14 pm
Przyłączę się do wątku z pytaniem.
Jaki "większy" kontroler można polecić na start ? Tak, żeby miał:
1) Prosty system operacyjny
2) Możliwośc pisania aplikacji w Javie
3) ethernet
4) IO, RS232, SPI itp.
5) Sesnowne środowisko dla dewelopera
cepu69
Guest
Guest
Fri Feb 19, 2010 1:15 pm
Dariusz Zolna wrote:
Quote:
Adam Dybkowski pisze:
W dniu 2010-02-16 20:01, Dariusz Zolna pisze:
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.
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.
"Wybor nalezy do Ciebie" Minister Zdrowia i Opieki Spolecznej
W dniu 2010-02-16 20:01, Dariusz Zolna pisze:
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.
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.
"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.
Quote:
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).
W przypadku u-boota takze vivi - obraz uruchamianego systemu/programu
flashu, bo póki co uruchamiam go tylko z poziomu supervivi (taki
bootloader z menu, czy jak chińczyki go nazywają - BIOS).
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
Adam Dybkowski
Guest
Guest
Mon Feb 22, 2010 9:15 pm
W dniu 2010-02-19 12:14, William Bonawentura pisze:
Quote:
Jaki "większy" kontroler można polecić na start ? Tak, żeby miał:
1) Prosty system operacyjny
2) Możliwośc pisania aplikacji w Javie
3) ethernet
4) IO, RS232, SPI itp.
5) Sesnowne środowisko dla dewelopera
1) Prosty system operacyjny
2) Możliwośc pisania aplikacji w Javie
3) ethernet
4) IO, RS232, SPI itp.
5) Sesnowne środowisko dla dewelopera
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.
--
Adam Dybkowski
http://dybkowski.net/
Uwaga: przed wysłaniem do mnie maila usuń cyfry z adresu.
elektroda NewsGroups Forum Index - Elektronika Polska - Gdzie znaleźć kompletny projekt 'Hello World' na ARM9 z GCC i makefile?