Elektroda.pl
Elektroda.pl
X
Arrow Multisolution Day
Proszę, dodaj wyjątek www.elektroda.pl do Adblock.
Dzięki temu, że oglądasz reklamy, wspierasz portal i użytkowników.

[C/Eclipse/LPC2468] - Błąd kompilacji "undefined reference to `_exit"

ADI-mistrzu 10 Paź 2013 14:31 3801 26
  • #1 10 Paź 2013 14:31
    ADI-mistrzu
    Poziom 30  

    Witam,

    Próbuję programować mikroprocesor LPC2468 pod Eclipse z wykorzystaniem kompilatora Yagarto.

    Zainstalowałem wtyczkę dla Eclipse:
    GNU ARM C/C++ Development Support

    Utworzyłem projekt, podlinkowałem bibliotekę i cały program wygląda tak:

    Kod: c
    Zaloguj się, aby zobaczyć kod

    Czyli w sumie nic to nie robi, spróbowałem więc co skompilować i dostaję:
    Kod: bash
    Zaloguj się, aby zobaczyć kod


    I powiem szczerze że nie wiem jak to ugryść, lpc2468.h wziąłem stąd:
    http://read.pudn.com/downloads192/sourcecode/embed/902507/hpi/LPC2468.h__.htm

    Pozdrawiam

    0 26
  • Arrow Multisolution Day
  • #2 10 Paź 2013 15:01
    mickpr
    Poziom 39  

    Gdzie masz linker skrypt? Masz go w ogóle?
    Co z plikami "startowymi" (np. Startup.s)?
    Poszukaj jakiegoś przykładu i podejrzyj sobie jak to jest zrealizowane.
    Np. tutaj: https://github.com/zolkko/lpc2468-dh-example
    ( https://github.com/zolkko/lpc2468-dh-example/archive/master.zip )
    Akurat ten przykład jest z Mac OSX, więc "tylko podejrzyj". Skompilować się nie da (zły toolchain).

    Zamieść projekt (wyeksportuj do ZIP), to go poprawimy.

    0
  • #3 11 Paź 2013 10:05
    ADI-mistrzu
    Poziom 30  

    Przerobiłem tamten projekt i kompilacja ruszyła.

    W załączniku wrzucam go, mógł by ktoś sprawdzić czy jest faktycznie ok?

    Mam wątpliwości co do boot.s, czy tamten kod jest wykonywany najpierw, zaraz po uruchomieniu CPU?

    0
  • #4 11 Paź 2013 11:52
    mickpr
    Poziom 39  

    ADI-mistrzu napisał:
    Przerobiłem tamten projekt i kompilacja ruszyła.
    O wiele lepszym rozwiązaniem jest stworzenie projektu od zera, tylko podglądając tamten.
    Wiem, że Eclipse nie lubi ręcznego grzebania w projektach, a szczególnie zmian toolchain-ów.

    ADI-mistrzu napisał:
    Mam wątpliwości co do boot.s, czy tamten kod jest wykonywany najpierw, zaraz po uruchomieniu CPU?
    Tak i służy między innymi do ustawiania wskaźnika stosu, handlerów itd..

    0
  • #5 12 Paź 2013 01:13
    mr_theo
    Poziom 10  

    Pozwolę sobie dopisać się do wątku, bo zasadniczo mam identyczny problem. Od jakiegoś czasu dłubię przy FreeRTOS na moim LPC2468 - idzie raz lepiej, raz gorzej, ale zawsze błędy kompilacji były sensowne. Ostatnio jednak do projektu zacząłem dołączać FatFS w celu obsługi karty SD i niestety, ale przy próbie kompilacji pojawia się błąd undefined reference to 'disk_initialize' (lub "f_open", "f_close" itd.).

    Myślałem, że gdzieś w kodzie popełniłem błąd, dlatego obciąłem nowy kod (w stosunku do tego, który się normalnie kompilował bez błędu) do absolutnego minimum, ale dalej jest to samo. Poniżej wspomniane linijki (z pliku main.c):

    Kod: c
    Zaloguj się, aby zobaczyć kod


    Wszystkie biblioteki FatFS wrzucam do katalogu FreeRTOS\Source\include (zresztą to jedyne miejsce do wrzucania include'ów).

    [C/Eclipse/LPC2468] - Błąd kompilacji "undefined reference to `_exit"

    Potem sprawdziłem, czy przypadkiem nie mam skopanych bibliotek, ale zarówno na oryginalnych plikach FatFS (pobranych stąd), jak i na bibliotekach z dema ze strony FreeRTOSa (link) cały czas jest ten sam problem.

    Wychodzi więc na to, że kompilator / linker po prostu nie widzi include'ów, albo zachowuje się tak, jakby były błędne. Może więc jest to problem z makefile? Byłoby to jednak dziwne, bo nic tam nie zmieniałem, a jak do tej pory wszystko śmigało. Załączam mojego makefile'a:

    Kod: c
    Zaloguj się, aby zobaczyć kod


    Także mnie już ręce opadają, nie mam więcej pomysłów. Byłby wdzięczny za wszelkie podpowiedzi ;)

    Kompiluję z linii komend (toolchain arm-2011.03-42-arm-none-eabi), nie mam Eclipse'a, ani innego środowiska zainstalowanego (używam Notepada++).

    0
  • Arrow Multisolution Day
  • #6 12 Paź 2013 08:41
    Freddie Chopin
    Specjalista - Mikrokontrolery

    mr_theo napisał:
    Wszystkie biblioteki FatFS wrzucam do katalogu FreeRTOS\Source\include (zresztą to jedyne miejsce do wrzucania include'ów).

    Nie wiem w jaki sposób można folder FreeRTOSa potraktować jako miejsce do wrzucania WSZYSTKICH plików nagłówkowych...

    mr_theo napisał:
    Wychodzi więc na to, że kompilator / linker po prostu nie widzi include'ów, albo zachowuje się tak, jakby były błędne.

    Błąd który widzisz nie pochodzi od kompilatora narzekającego że nie widzi nagłówków, tylko od linkera narzekającego że nie widzi skompilowanych funkcji wymaganych przez inne funkcje.

    Teraz więc po prostu zastanów się, w którym miejscu KOMPILUJESZ tą bibliotekę...

    4\/3!!

    0
  • #7 12 Paź 2013 14:23
    mickpr
    Poziom 39  

    mr_theo napisał:
    Kompiluję z linii komend (toolchain arm-2011.03-42-arm-none-eabi), nie mam Eclipse'a, ani innego środowiska zainstalowanego (używam Notepada++).
    Dość karkołomne rozwiązanie (żeby nie powiedzieć - "głupie").
    Gdybyś nie męczył na siłę sposobu "Makefile" - zaręczam ci, ze z GNU Arm Eclispe Plugin wszystko zadziałało by od ręki... ale cóż....
    Oczywiście wiem, że niektórzy uwielbiają wprost Makefile-y....
    Ja też - ale tylko przy programach w Linux'ie których sam nie muszę pisać.

    mr_theo napisał:
    Ostatnio jednak do projektu zacząłem dołączać FatFS w celu obsługi karty SD i niestety, ale przy próbie kompilacji pojawia się błąd undefined reference to 'disk_initialize' (lub "f_open", "f_close" itd.).
    Zakładam, że nie czytałeś w ogóle instrukcje od FatFs.
    Gdybyś czytał - wiedziałbyś, że musisz zdefiniować sobie niektóre funkcje właśnie jak "disk_initialize".
    Masz biblioteki od SPI? Przecież jakoś kartę SD podłączasz, prawda?
    To właśnie tam powinna "polecieć" inicjalizacja SPI.
    A co z kolejnymi funkcjami - jak disk_read, disk_write, disk_status, disk_ioctl .... (itd)?

    Nie podałeś nawet logu z kompilacji... Chcesz abyśmy bawili się we wróżów/wróżki?

    Moim zdaniem (to do moderatorów) ten wątek powinien zostać wydzielony jako odrębny post.

    0
  • #8 12 Paź 2013 19:21
    Freddie Chopin
    Specjalista - Mikrokontrolery

    mickpr napisał:
    Gdybyś nie męczył na siłę sposobu "Makefile" - zaręczam ci, ze z GNU Arm Eclispe Plugin wszystko zadziałało by od ręki... ale cóż....

    Zadziałałoby zaraz po tym jak wyklikasz sobie 40000 opcji przy użyciu ptaszków, list i pól tekstowych (; No tak, dużo lepsze niż Makefile <:

    mickpr napisał:
    Oczywiście wiem, że niektórzy uwielbiają wprost Makefile-y....
    Ja też - ale tylko przy programach w Linux'ie których sam nie muszę pisać.

    Napisałem w życiu JEDNEGO makefile'a. Teraz tylko przerabiam w nim trywialne rzeczy typu nazwa projektu i foldery do kompilacji. Mordęga...

    4\/3!!

    0
  • #9 12 Paź 2013 20:04
    mickpr
    Poziom 39  

    @Freddie Chopin : De gustibus no disputandum est - prawda?
    Jeden woli ogórki, a drugi ogrodnika córki.

    Ja używam Eclipse NIE TYLKO dlatego, że ma dobry edytor (w sumie to widziałem parę lepszych), ale również za to, że pomaga mi trzymać w miarę sensowny ład - co do plików projektu i ich kompilacji oraz zarządzaniem całością.
    Makefile ma plusy (nie mówię, że nie) i sposób z "wizualnym konfiguratorem Makefile" też ma plusy.
    Eclipse umożliwia używanie jednego i drugiego.
    Używam tego drugiego dlatego, że jest, i dla mnie jest łatwiejszy.
    Gdyby był "godny potępienia" - to by "umarł", a jednak trzyma się dość dobrze (ostatnia aktualizacja 20 godzin temu).

    0
  • #10 12 Paź 2013 20:21
    mr_theo
    Poziom 10  

    Freddie Chopin napisał:
    Nie wiem w jaki sposób można folder FreeRTOSa potraktować jako miejsce do wrzucania WSZYSTKICH plików nagłówkowych...

    Ok, ale jeśli biblioteki z roszerzeniem *h wrzucę do folderu FreeRTOS\Source\include, a te z roszerzeniem *c do folderu FreeRTOS\Source - nie ma różnicy. Wywala ten sam błąd.

    Freddie Chopin napisał:
    Błąd który widzisz nie pochodzi od kompilatora narzekającego że nie widzi nagłówków, tylko od linkera narzekającego że nie widzi skompilowanych funkcji wymaganych przez inne funkcje.
    Teraz więc po prostu zastanów się, w którym miejscu KOMPILUJESZ tą bibliotekę...

    Pogubiłem się (a mam na ten temat wybiórczą wiedzę, przyznaję z góry, więc jest mi o to łatwo) - piszesz, że linker widzi, dajmy na to diskio.h, ale jeśli w diskio.h jest dołączony integer.h, to jest on niewidoczny dla linkera, a powodem tego jest błędna lokalizacja bibliotek (wrzucam część z nich do nieodpowiedniego miejsca)?

    mickpr napisał:
    Dość karkołomne rozwiązanie (żeby nie powiedzieć - "głupie").
    Gdybyś nie męczył na siłę sposobu "Makefile" - zaręczam ci, ze z GNU Arm Eclispe Plugin wszystko zadziałało by od ręki... ale cóż....
    Oczywiście wiem, że niektórzy uwielbiają wprost Makefile-y....
    Ja też - ale tylko przy programach w Linux'ie których sam nie muszę pisać.

    Nie jestem jakimś fanatykiem konsoli, ale po prostu nie miałem do tej pory żadnego powodu, żeby męczyć się z konfiguracją Eclipse'a pod moją podstawkę, zwłaszcza że notepad++ do wszystkiego mi wystarczał. Jeśli jednak jesteś pewny, że wystarczy go zainstalować, a wszystkie moje problemy magicznie znikną, to od razu poszukam sobie instrukcji konfiguracji ;)

    mickpr napisał:
    Zakładam, że nie czytałeś w ogóle instrukcje od FatFs.
    Gdybyś czytał - wiedziałbyś, że musisz zdefiniować sobie niektóre funkcje właśnie jak "disk_initialize".

    Jeśli mówisz o czymś takim:
    Kod: c
    Zaloguj się, aby zobaczyć kod

    ...to nic nie zmienia w sprawie mojego błędu.

    mickpr napisał:
    Masz biblioteki od SPI? Przecież jakoś kartę SD podłączasz, prawda?
    To właśnie tam powinna "polecieć" inicjalizacja SPI.

    Na razie nie mam czego podłączać, bo kod się nie kompiluje --> nie mam hexa, nie mam czego wrzucać na płytkę. Ale z przykładu ze strony FreeRTOSa (link w moim poprzednim poście) pobrałem sobie cały folder z bibliotekami, jest tam FatFS i plik mmc.h, jak go wrzucę do siebie, to dalej jest to samo.

    mickpr napisał:
    A co z kolejnymi funkcjami - jak disk_read, disk_write, disk_status, disk_ioctl .... (itd)?

    Na razie skupmy się tylko przy disk_initialize - w kodzie jest tylka ta komenda, a i tak wyskakuje błąd. Jeśli rozwiążemy ten problem, to będę wiedział, jak poradzić sobie z podobnymi.

    mickpr napisał:
    Nie podałeś nawet logu z kompilacji... Chcesz abyśmy bawili się we wróżów/wróżki?

    Proszę bardzo:

    Kod: c
    Zaloguj się, aby zobaczyć kod

    mickpr napisał:
    Moim zdaniem (to do moderatorów) ten wątek powinien zostać wydzielony jako odrębny post.

    Przed napisaniem pierwszego posta miałem podobny dylemat (stworzyć nowy temat, czy się dopisać). Spytałem moderatora, kazał się dopisać.

    0
  • #11 12 Paź 2013 20:46
    mickpr
    Poziom 39  

    mr_theo napisał:
    Ok, ale jeśli biblioteki z roszerzeniem *h wrzucę do folderu FreeRTOS\Source\include, a te z roszerzeniem *c do folderu FreeRTOS\Source - nie ma różnicy. Wywala ten sam błąd.
    Dlaczego uparcie wrzucasz wszystkie koty do jednego worka o nazwie FreeRTOS.
    Załóż sobie własne foldery i nie rób bałaganu.
    mr_theo napisał:
    Nie jestem jakimś fanatykiem konsoli, ale po prostu nie miałem do tej pory żadnego powodu, żeby męczyć się z konfiguracją Eclipse'a pod moją podstawkę, zwłaszcza że notepad++ do wszystkiego mi wystarczał. Jeśli jednak jesteś pewny, że wystarczy go zainstalować, a wszystkie moje problemy magicznie znikną, to od razu poszukam sobie instrukcji konfiguracji
    Same nie znikną.. trzeba poznać narzędzie, którego się zamierza używać.
    mr_theo napisał:
    Jeśli mówisz o czymś takim:
    Nie...
    Dam ci przykład jak to wygląda u mnie (LPC1768)..
    Kod: c
    Zaloguj się, aby zobaczyć kod

    Czy teraz widzisz wywołanie sdInit() ?
    Czy już wiesz, że musisz sobie te funkcje zdefiniować samemu? Autor FatFS nie mógł ich dla Ciebie stworzyć, bo nie wiedział gdzie będziesz jego kod uruchamiał, ani na jakim MCU, ani podpięty pod jakie piny. To jest powód, że musisz zrobić to SAM.

    mr_theo napisał:
    Na razie nie mam czego podłączać, bo kod się nie kompiluje --> nie mam hexa, nie mam czego wrzucać na płytkę. Ale z przykładu ze strony FreeRTOSa (link w moim poprzednim poście) pobrałem sobie cały folder z bibliotekami, jest tam FatFS i plik mmc.h, jak go wrzucę do siebie, to dalej jest to samo.
    Nie słuchasz mnie i dalej uparcie robisz swoje.
    Nie masz czego wrzucać, bo nie podłączyłeś SPI, nie wiesz pod jakie piny, więc kodu nie napiszesz. Proste?
    mr_theo napisał:
    Na razie skupmy się tylko przy disk_initialize - w kodzie jest tylka ta komenda, a i tak wyskakuje błąd. Jeśli rozwiążemy ten problem, to będę wiedział, jak poradzić sobie z podobnymi.
    Zerknij na mój przykład (wyżej).
    mr_theo napisał:
    Przed napisaniem pierwszego posta miałem podobny dylemat (stworzyć nowy temat, czy się dopisać). Spytałem moderatora, kazał się dopisać.
    To OK.

    0
  • #12 12 Paź 2013 20:53
    Freddie Chopin
    Specjalista - Mikrokontrolery

    mr_theo napisał:
    Pogubiłem się (a mam na ten temat wybiórczą wiedzę, przyznaję z góry, więc jest mi o to łatwo) - piszesz, że linker widzi, dajmy na to diskio.h, ale jeśli w diskio.h jest dołączony integer.h, to jest on niewidoczny dla linkera, a powodem tego jest błędna lokalizacja bibliotek (wrzucam część z nich do nieodpowiedniego miejsca)?

    Linker nie ma pojęcia co to są pliki .h czy .c. Dla linkera istnieją tylko i wyłącznie pliki z rozszerzeniem .o (skompilowane pliki .c) i pliki z rozszerzeniem .a (biblioteki statyczne, w rzeczywistości jest to "archiwum" z plikami .o). Dla linkera nie mają ŻADNEGO znaczenia pliki nagłówkowe i to który dołącza który. Dla kompilatora w zasadzie również ma to niewielkie znaczenie, bo jego interesuje funkcja. Nie taka którą masz zadeklarowaną w nagłówku, tylko taka którą on faktycznie skompilował w pliku .c. I to właśnie takich skompilowanych funkcji (plików .o) nie widzi linker. Bo on ma jeden plik .o który mówi mu "potrzebuję funkcji xyz()", a tejże funkcji nie ma w żadnym pliku poddanym procesowi linkowania.

    mr_theo napisał:
    main.o: In function `main':
    C:\Users\user\Desktop\test\FreeRTOS\Demo\ARM7_LPC2368_Eclipse\RTOSDemo/main.c:
    177: undefined reference to `disk_initialize'

    W Twoim projekcie musi znajdować się KOD funkcji o takiej nazwie. Kod ten musi zostać skompilowany do pliku .o, a następnie musi zostać podany do linkowania. Nie dość że Twoja kompilacja nie kompiluje nawet gołego FatFS (pliku ff.c), to samej definicji funkcji disk_initialize() zapewne też nie. A Makefile którego używasz jest wyjątkowo kiepski, bo podaje te same flagi dla linkowania i kompilacji, co jest całkowicie bezsensowne, aż dziw że w ogóle poprawne...

    To że jakieś pliki gdzieś wrzucisz, to nie znaczy jeszcze że zostaną one skompilowane - równie dobrze pliki do kompilacji mogą być podane wprost w Makefile, więc jeśli nowych plików tam nie nie dopiszesz, to po prostu nigdy nie zostaną skompilowane i zlinkowane.

    4\/3!!

    0
  • #13 12 Paź 2013 21:06
    mr_theo
    Poziom 10  

    Freddie Chopin napisał:
    A Makefile którego używasz jest wyjątkowo kiepski, bo podaje te same flagi dla linkowania i kompilacji, co jest całkowicie bezsensowne, aż dziw że w ogóle poprawne...

    Makefile jest pobrany w pakiecie z FreeRTOSem, zmieniłem tylko dwie linijki dot. mojego toolchaina. Całą winę zwalam więc na twórców FreeRTOSa :D

    Ok, Freddie Chopin, mickpr - dzięki za wskazówki. Postaram się przez nie przegryźć, co może zająć parę dni. Jak z tego przegryzania jakieś dalsze pytania wynikną, dam znać.

    [edit - literówka]

    0
  • #14 12 Paź 2013 21:15
    Freddie Chopin
    Specjalista - Mikrokontrolery

    Zajrzyj lepiej do tego Makefile'a, bo ja podejrzewam, że tam na 99% są wszystkie pliki źródłowe wyszczególnione wprost, więc jak nie dopiszesz tych które dodajesz, to nic z tego nie będzie. Albo go tu po prostu wrzuć. Najlepiej z całym projektem. Tyle że ten projekt mógłbyś odchudzić z niepotrzebnych rzeczy typu webserver, bo dla dyskutowanego tutaj problemu nie ma on żadnego znaczenia.

    4\/3!!

    0
  • #15 12 Paź 2013 21:21
    mr_theo
    Poziom 10  

    Makefile wrzucałem już w moim pierwszym poście (LINK). Jakby dalej była potrzeba załączenia całego projektu, daj znać, to wrzucę.

    0
  • #16 12 Paź 2013 21:22
    mickpr
    Poziom 39  

    mr_theo napisał:
    Całą winę zwalam więc na twórców FreeRTOSa
    Można zrzucić winę na kogoś, ale mądrzejszym się przez to nie staniesz.
    Podejrzyj inne projekty z FatFS (gotowe projekty). Dojdziesz do tego jak skonstruować swój własny.

    0
  • #17 12 Paź 2013 21:36
    Freddie Chopin
    Specjalista - Mikrokontrolery

    mr_theo napisał:
    Makefile wrzucałem już w moim pierwszym poście (LINK). Jakby dalej była potrzeba załączenia całego projektu, daj znać, to wrzucę.

    W zmiennych ARM_SOURCE i THUMB_SOURCE są wymienione pliki które zostaną skompilowane i - potem - zlinkowane. Każdy nowy plik .c musisz dopisać do odpowiedniej grupy (proponuję wybrać tą gdzie jest więcej plików, czyli thumb).

    mickpr napisał:
    Można zrzucić winę na kogoś, ale mądrzejszym się przez to nie staniesz.

    No ale ten Makefile akurat jest kiepski (;

    Generalnie pewną opcją jest też skorzystanie z szablonów projektów [;
    https://www.elektroda.pl/rtvforum/topic1339518-0.html
    https://www.elektroda.pl/rtvforum/topic1313509.html

    4\/3!!

    0
  • #18 12 Paź 2013 22:08
    mr_theo
    Poziom 10  

    Freddie Chopin napisał:
    W zmiennych ARM_SOURCE i THUMB_SOURCE są wymienione pliki które zostaną skompilowane i - potem - zlinkowane. Każdy nowy plik .c musisz dopisać do odpowiedniej grupy (proponuję wybrać tą gdzie jest więcej plików, czyli thumb).

    Zrobiłem porządek z folderami, dokleiłem do makefile'a. Wywala błąd:
    Kod: c
    Zaloguj się, aby zobaczyć kod

    Freddie Chopin napisał:
    Generalnie pewną opcją jest też skorzystanie z szablonów projektów [;
    https://www.elektroda.pl/rtvforum/topic1339518-0.html
    https://www.elektroda.pl/rtvforum/topic1313509.html

    Dzięki za linki, potem na pewno się przez nie przegryzę! :)
    mickpr napisał:
    Można zrzucić winę na kogoś, ale mądrzejszym się przez to nie staniesz.
    Podejrzyj inne projekty z FatFS (gotowe projekty). Dojdziesz do tego jak skonstruować swój własny.

    Przecież żartowałem, byłem pewny, że emota na końcu wyraźnie to mówi.
    Jasne, na projekty zawsze sobie patrzę. Trzeba jednak uczciwie powiedzieć, że tym razem nie za wiele z nich wyniosłem.

    0
  • #19 13 Paź 2013 09:52
    Freddie Chopin
    Specjalista - Mikrokontrolery

    mr_theo napisał:
    Zrobiłem porządek z folderami, dokleiłem do makefile'a. Wywala błąd:

    Obstawiam że folder jest zły - za dużo lub za mało "..". Kompilacja jest uruchamiana z folderu w którym znajduje się Makefile (pomijamy ekstremalne przypadki), więc to względem tego pliku muszą być podane wszystkie (względne) ścieżki.

    I czy naprawdę folder "Include" jest dobry na źródła?

    4\/3!!

    0
  • #20 13 Paź 2013 23:51
    mr_theo
    Poziom 10  

    Freddie Chopin napisał:
    Obstawiam że folder jest zły - za dużo lub za mało "..". Kompilacja jest uruchamiana z folderu w którym znajduje się Makefile (pomijamy ekstremalne przypadki), więc to względem tego pliku muszą być podane wszystkie (względne) ścieżki.

    Faktycznie, masz rację. To był głupi błąd z mojej strony. Teraz co prawda dalej się nie kompiluje, ale błąd jest już zrozumiały - w diskio.c są dołączone:
    Kod: c
    Zaloguj się, aby zobaczyć kod

    których tak naprawdę nie ma. No ale przynajmniej wiem już, na czym stoję, będę sobie teraz na spokojnie dłubał. Jeszcze raz dzięki za wskazanie właściwego kierunku, jak będę miał jakieś pytania, to się odezwę.

    Freddie Chopin napisał:
    I czy naprawdę folder "Include" jest dobry na źródła?

    Folder jak każdy inny. Dla mnie najbardziej logiczna lokalizacja, dla ciebie najwyraźniej nie ;)

    0
  • #21 14 Paź 2013 00:39
    mickpr
    Poziom 39  

    mr_theo napisał:
    Folder jak każdy inny. Dla mnie najbardziej logiczna lokalizacja, dla ciebie najwyraźniej nie
    Gdybym był złośliwy, zaproponował bym C:\WINDOWS.

    0
  • #22 17 Gru 2013 14:52
    ADI-mistrzu
    Poziom 30  

    A posiada ktoś może skrypt linkera razem z vektorami przerwań dla lpc2468?

    Czy raczej trzeba samemu sobie zrobić?

    0
  • #24 18 Gru 2013 12:37
    ADI-mistrzu
    Poziom 30  

    Wygrzebałem skrypty skądś indziej razem ze startup'em, tablicę wektorów wziąłem tymczasowo od LPC175x/LPC176x, nie mogłem doszukać się pod ten.

    Niestety w czasie kompilacji linker wypluwa między innymi:

    Kod: bash
    Zaloguj się, aby zobaczyć kod


    W skrypcie od tego mam:
    Kod: c
    Zaloguj się, aby zobaczyć kod

    Jeśli ujmę część w nawiasy w ten sposób:
    Kod: c
    Zaloguj się, aby zobaczyć kod

    Błąd przestaje się pojawiać, lecz niestety nie znam skryptu linkera i nie wiem czy jest w nim błąd czy może ja robię tutaj babola.

    W załączniku projekt w Eclipse.

    0
  • #25 18 Gru 2013 12:45
    ADI-mistrzu
    Poziom 30  

    Wziąłem wszystkie błędy w ten nawiasy lecz niestety efektem kompilacji jest program o wielkości równej 0.

    0
  • #27 19 Gru 2013 09:29
    ADI-mistrzu
    Poziom 30  

    Projekt od zolkko jest mocno okrojony (ta tablica to obszerna nie jest...), a drugi link w ogóle jej niema (a przynajmniej nic tam nie widzę).

    Gdy wpisuję w google to wyskakuje kupa stron z odnośnikami do sklepów, ofert, potem tematy z problemami gdzie niema kodów itd.

    To google chyba kiedyś lepiej wyszukiwało...

    0