Forum elektroda.pl

Regulamin  | Punkty  | Dodaj...  | Ostatnie  | Szukaj  | Rejestracja  | Zaloguj

Ta strona używa cookie. Dowiedz się więcej o celu ich używania i zmianie ustawień cookie w przeglądarce.
Korzystając ze strony wyrażasz zgodę na używanie cookie, zgodnie z aktualnymi ustawieniami przeglądarki.

Przykładowe projekty dla ARMów


Napisz nowy temat  Odpowiedz do tematu      Strona Główna -> Forum elektroda.pl -> Mikrokontrolery Ogólne -> Mikrokontrolery ARM -> Przykładowe projekty dla ARMów
Autor
Wiadomość
Freddie Chopin
Specjalista - Mikrokontrolery
Specjalista - Mikrokontrolery


Dołączył: 12 Gru 2005
Posty: 9841
Miasto: Zawiercie

Post#1 Post autora tematu 12 Cze 2009 14:00   

Przykładowe projekty dla ARMów


Na swojej stronie ( www.freddiechopin.info ) w dziale Download > ARM > Przykłady umieszczone zostały dwa przykładowe projekty pod Eclipse - jeden dla NXP LPC2103, drugi dla ST STM32F103RB. Przykłady te (w założeniu) są dopełnieniem artykułu ze strony o nazwie ARM toolchain - tutorial (na stronie w dzale Artykuły > ARM, dyskusja na forum - http://www.elektroda.pl/rtvforum/topic1313509.html), a więc w dużej części bazują na przedstawionych tam schematach postępowania. W projektach zawarte są wszystkie podstawowe pliki - Makefile, skrypt linkera, startup, tablica wektorów. Do tego skonfigurowane skróty do debuggowania (External Tool oraz Debug Configuration). W kodzie głównym, poza miganiem diodką z ustalaną prędkością, znajduje się podstawowa konfiguracja systemu, taka jak aktywacja wszelkich akceleratorów pamięci Flash oraz ustawienie przy pomocy PLL maksymalnej prędkości rdzenia. Projekty w katalogu doc/ zawierają kompletną dokumentację wygenerowaną w Doxygen, na podstawie której łatwiej będzie je modyfikować do własnych potrzeb.

Załączone do przykładów pliki Makefile do 100% poprawnego działania wymagają kilku plików z GNU Coreutils (poza make: echo, mkdir, rm, sh). Instalator dla systemu Windows z podstawowymi plikami znaleźć można również na mojej stronce w dziale Download > Programy > Coreutils. Pliki te dostępne są również w pakiecie WinAVR. Bez wymienionych plików konieczne jest ręczne stworzenie w projekcie folderu dla generowanych plików (domyślna nazwa tego folderu zawarta jest w Makefile w linii OUTPUT_DIR = ./out/ ) lub kompilowanie bezpośrednio do folderu głównego (wystarczy ustawić brak katalogu - OUTPUT_DIR = ).

Wszelkie uwagi dotyczące tych kodów, jak i paczki z GNU Coreutils, wrzucajcie tutaj, jako komentarze do newsa o tych przykładach na stronie, lub poprzez forumlarz kontaktowy na stronie. Proszę też o kontakt jeśli ktoś chciałby pomóc w stworzeniu takich przykładów dla innych układów z rdzeniem ARM (AT91SAM, ADuC, STR7, STR9, LM, ...) - ze swojej strony pomogę jak tylko będę mógł.

4\/3!!

Moderowano przez And!:
Temat podlinkowany w postach przyklejonych

Powrót do góry
   
Freddie Chopin
Specjalista - Mikrokontrolery
Specjalista - Mikrokontrolery


Dołączył: 12 Gru 2005
Posty: 9841
Miasto: Zawiercie

Post#2 Post autora tematu 19 Wrz 2009 17:05   

Re: Przykładowe projekty dla ARMów


Przykładowe projekty dla procesorów NXP LPC2103 i ST STM32F103RB umieszczone na mojej stronie w dziale Download > ARM > Przykłady, doczekały się nowej wersji. Zmiany wprowadzone do przykładów dotyczą głównie tych elementów, o istnieniu których łatwo zapomnieć - tablicy wektorów, skryptu linkera, pliku Makefile, pliku startup.

Lista najważniejszych zmian:
- wsparcie dla C++ w skrypcie linkera, pliku Makefile i pliku startup (włączane w pliku Makefile zmienną USES_CPP),
- zmiana w pliku Makefile i / lub w skrypcie linkera powoduje ponowną kompilację źródeł i / lub linkowanie obiektów,
- tablica wektorów i funkcja __Default_Handler() w C, a nie w assemblerze,
- zmiana skrótu do OpenOCD na odpowiedni dla aktualnej wersji 0.2.0,
- pomniejsze zmiany w nazwach, formatowaniu, itp.,
- (LPC2103) skróty do GDB zawierają opcje, dzięki którym debuggowanie jest bardziej niezawodne,
- (STM32) pliki nagłówkowe zawarte w folderze inc/ pochodzą z stm32f10x_stdperiph_lib v.3.1.0 (najnowsza wersja).

Wyjaśnienia może wymagać kwestia zwiększenia niezawodności debuggowania LPC2103. Sprawa jest skomplikowana, więc przedstawię ideę jedynie w skrócie. Ze względu na mechanizmy zastosowane przez producenta układów z serii LPC2xxx procesor rozpoczynający sesję debuggowania wykonał już pewną część wgranego kodu. Nie jest możliwe pełne zresetowanie układu i natychmiastowe zatrzymanie rdzenia. Jeśli w kodzie włączany jest MAM lub PLL, to na początku sesji debuggowania na 99% będą one już włączone (rdzeń zdążył już wykonać kod odpowiedzialny za uruchomienie tych peryferiów). Z tego względu podczas debuggowania mogą występować nieoczekiwane i bezsensowne błędy, a procesor może zachowywać się w sposób nieprzewidywalny. Skróty do GDB, które zawarte są obecnie w przykładach, za pomocą komend OpenOCD wyłączają zarówno MAM jak i PLL przed rozpoczęciem sesji (co oczywiście nie wyklucza możliwości ponownego ich włączenia w kodzie), dzięki czemu problemy te nie powinny występować.

4\/3!!
Powrót do góry
   
atom1477
Poziom 25
Poziom 25


Dołączył: 14 Lip 2005
Posty: 8068

Post#3 21 Wrz 2009 09:54   

Re: Przykładowe projekty dla ARMów


Mogę wiedzieć skąd wziąłeś te liczby:

Cytat:
void (* const vectors[])(void) __attribute__ ((section(".vectors"))) = {
(void (*)(void))0xe59ff018, // "Reset" vector
(void (*)(void))0xe59ff018, // "Undefined instruction" vector
(void (*)(void))0xe59ff018, // "Software interrupt (SWI)" vector
(void (*)(void))0xe59ff018, // "Prefetch Abort (instruction fetch memory abort)" vector
(void (*)(void))0xe59ff018, // "Data Abort (data access memory abort)" vector
(void (*)(void))0, // Reserved vector (code signature)
(void (*)(void))0xe51ffff0, // "IRQ" vector
(void (*)(void))0xe59ff010, // "FIQ (fast interrupt)" vector
Reset_Handler, // Reset
Undefined_Handler, // Undefined instruction
SWI_Handler, // Software interrupt (SWI)
Prefetch_Abort_Handler, // Prefetch Abort (instruction fetch memory abort)
Data_Abort_Handler, // Data Abort (data access memory abort)
FIQ_Handler // FIQ (fast interrupt)
};


?


Chciałem to przerobić dla LPC2478 bo może przez to nie działają mi przerwania, ale najpierw chciałem się upewnić że wiem o co chodzi i sprawdziłem czy te adresy zgadzają się z tym co pisze w nocie katalogowej LPC210x.
No i niestety trochę zwątpiłem, bo tam jest tak:
Przykładowe projekty dla ARMów

Jeszcze obstawiałem na to że adresy są przesunięte do RAMu, ale tez nie, bo RAM jest od 0x40000000.
Chyba jeszcze czegoś brakuje mi w startupie do uruchomienia przerwań, ale to zostawiam na później.
Z góry dziękuję za pomoc.
Powrót do góry
   
Freddie Chopin
Specjalista - Mikrokontrolery
Specjalista - Mikrokontrolery


Dołączył: 12 Gru 2005
Posty: 9841
Miasto: Zawiercie

Post#4 Post autora tematu 21 Wrz 2009 11:13   

Re: Przykładowe projekty dla ARMów


To nie są adresy, tylko skompilowana postać instrukcji assemblerowych z tabelki powyżej. To jedyny sposób (który znam), aby zrobić dla ARM7 tabelę wektorów w C.

Przerwania nie działają Ci z dwóch powodów:

1. W skrypcie linkera standardowo ustawione są zerowe rozmiary stosu dla innych trybów niż User

2. W LPC2478 adres rejestru VicVectAddr jest inny niż dla LPC2103. W LPC2103 jest to 0xFFFF F030, w LPC2478 - 0xFFFF FF00.

Aby rozwiązać sprawę z punktu 2. musisz podstawić za instrukcję "ldr pc, [pc, #-0xFF0]" postawić odpowiednik dla LPC2478 - "ldr pc, [pc, #-0x120]". Innymi słowy - zastąp "0xe51ffff0" wartością "e51ff120". Jeśli chcesz sam to sprawdzić to wpisz sobie gdzieś w main:

asm volatile ("ldr pc, [pc, #-0x120]");

Swoją drogą chętnie poznam opinię na temat tak trickowej realizacji tablicy wektorów [;

4\/3!!
Powrót do góry
   
atom1477
Poziom 25
Poziom 25


Dołączył: 14 Lip 2005
Posty: 8068

Post#5 21 Wrz 2009 14:20   

Re: Przykładowe projekty dla ARMów


Freddie Chopin napisał:
To nie są adresy, tylko skompilowana postać instrukcji assemblerowych z tabelki powyżej. To jedyny sposób (który znam), aby zrobić dla ARM7 tabelę wektorów w C.


Ja pierniczę. Nawet przeszło mi to przez myśl, ale od razu to odrzuciłem bo nie sądziłem że ktoś inny niż ja jest w stanie coś takiego zrobić. A co dopiero Ty, zwolennik uniwersalności i ułatwiania sobie życia ;p
Poza tym nie sądziłem że liczba 4-ro bajtowa zmieści się w 4-ro bajtowym rozkazie ;p Ale teraz się domyślam że jest tam tylko młodsza połówka albo coś jeszcze krótszego.
Tylko nie rozumiem dlaczego 5 pierwszych wektorów jest takich samych. Chyba powinny być inne. No chyba że po prostu nie ma dedykowanej obsługi tych wektorów i dlatego są przekierowane do jednego miejsca.
No i dopiero się zczaiłem że te adresy podane w nocie katalogowej to są adresy umieszczenia wektorów, a nie adresy wektorów ;p


Freddie Chopin napisał:
Przerwania nie działają Ci z dwóch powodów:

1. W skrypcie linkera standardowo ustawione są zerowe rozmiary stosu dla innych trybów niż User


Nie nie. To już dawno zmieniłem.

Freddie Chopin napisał:
2. W LPC2478 adres rejestru VicVectAddr jest inny niż dla LPC2103. W LPC2103 jest to 0xFFFF F030, w LPC2478 - 0xFFFF FF00.

Aby rozwiązać sprawę z punktu 2. musisz podstawić za instrukcję "ldr pc, [pc, #-0xFF0]" postawić odpowiednik dla LPC2478 - "ldr pc, [pc, #-0x120]". Innymi słowy - zastąp "0xe51ffff0" wartością "e51ff120". Jeśli chcesz sam to sprawdzić to wpisz sobie gdzieś w main:

asm volatile ("ldr pc, [pc, #-0x120]");


Ten VicVectAddr to ten uniwersalny rejestr do którego trzeba wpisać dowolną wartość podczas wychodzenia przerwania? Nie wiedziałem że on jeszcze do czegoś służy. No to zaraz sprawdzę.
A jak wyliczyłeś te liczby? Bo nie widzę związku pomiędzy 0xFFFFF030 a -0x0FF0 i pomiędzy 0xFFFFFF00 a -0x0120. Ani to przesunięcie (bo różne w obydwu przypadkach) ani zapis liczby ujemnej (bo też się nie zgadza).

Freddie Chopin napisał:

Swoją drogą chętnie poznam opinię na temat tak trickowej realizacji tablicy wektorów [;

4\/3!!


No na moje oko trochę naciągany ten sposób. Czy ma to jakieś specjalne zalety poza małą wadą że jest trochę ciężej zedytować adres?
A nie dało się jakoś umieścić stałych w pamięci programu pod określonym adresem?
Przy okazji: zawsze jak się ktoś o to pyta to słyszy odpowiedz że to podstawa C i jak ktoś tego nie wie to powinien się podszkolić a nie pytać o to na forum. No ale podszkalam się i podszkalam a nadal tego nie wiem. Mianowicie jak umieścić tablice stałych w pamięci programu? Najlepiej pod określonym adresem. Oczywiście stałe mają być w określonej kolejności. Na przykład jakaś tablica RGB, czyli jakiś obrazek.
Powrót do góry
   
Google


Google Adsense


Post# 21 Wrz 2009 14:20   





Powrót do góry
   
Freddie Chopin
Specjalista - Mikrokontrolery
Specjalista - Mikrokontrolery


Dołączył: 12 Gru 2005
Posty: 9841
Miasto: Zawiercie

Post#6 Post autora tematu 21 Wrz 2009 15:47   

Re: Przykładowe projekty dla ARMów


Po pierwsze - WSZYSTKO jest w komentarzu powyżej tej tabeli, tam jest podana postać assemblerowa - jak sobie ją skompilujesz, to otrzymasz DOKŁADNIE taki sam efekt.

atom1477 napisał:
Ja pierniczę. Nawet przeszło mi to przez myśl, ale od razu to odrzuciłem bo nie sądziłem że ktoś inny niż ja jest w stanie coś takiego zrobić. A co dopiero Ty, zwolennik uniwersalności i ułatwiania sobie życia ;p

Ułatwiłem sobie życie, bo plik jest w C <: Pozatym dla Cortex-M3 już jest to normalnie, bez takich cudów - jedynie ARMv4 wymaga takich akrobacji.

Cytat:
Poza tym nie sądziłem że liczba 4-ro bajtowa zmieści się w 4-ro bajtowym rozkazie ;p Ale teraz się domyślam że jest tam tylko młodsza połówka albo coś jeszcze krótszego.

Tam jest tylko offset, bo zastosowane jest adresowanie pośrednie z offsetem.

Cytat:
Tylko nie rozumiem dlaczego 5 pierwszych wektorów jest takich samych. Chyba powinny być inne. No chyba że po prostu nie ma dedykowanej obsługi tych wektorów i dlatego są przekierowane do jednego miejsca.

Takie same są rozkazy "załaduj do PC adres znajdujący się X bajtów dalej. Logicznym jest, że rozkaz taki umieszczony pod adresem 0 załaduje wartość znajdującą się pod 0 + X, natomiast rozkaz pod adresem 4 załaduje do PC adres z komórki 4 + X. Wszystko jest w najlepszym porządku.

Cytat:
No i dopiero się zczaiłem że te adresy podane w nocie katalogowej to są adresy umieszczenia wektorów, a nie adresy wektorów ;p

W architekturze ARMv4 w zasadzie nie są to typowe "wektory", czyli adres funkcji obsługi, tylko są to rozkazy które wykona rdzeń po wystapieniu wyjątku.

Cytat:
Ten VicVectAddr to ten uniwersalny rejestr do którego trzeba wpisać dowolną wartość podczas wychodzenia przerwania? Nie wiedziałem że on jeszcze do czegoś służy. No to zaraz sprawdzę.

Wszystko jest w datasheecie...

Cytat:
A jak wyliczyłeś te liczby? Bo nie widzę związku pomiędzy 0xFFFFF030 a -0x0FF0 i pomiędzy 0xFFFFFF00 a -0x0120. Ani to przesunięcie (bo różne w obydwu przypadkach) ani zapis liczby ujemnej (bo też się nie zgadza).

To jest przesunięcie względem aktualnej wartości PC (z tym że lekko większej, bo pipeline):
0xFFFFFF00 + 0x0120 = 0x20
0xFFFFF030 + 0x0FF0 = 0x20

Cytat:
No na moje oko trochę naciągany ten sposób. Czy ma to jakieś specjalne zalety poza małą wadą że jest trochę ciężej zedytować adres?

Podstawowe pytanie brzmi - po co edytować adres? Ta tabela nie wymaga żadnych zmian, nigdy i pod żadnym pozorem... Jeśli chcesz obsłużyć przerwanie, to po prostu piszesz w kodzie funkcję o odpowiedniej nazwie - np:
void Data_Abort_Handler(void) __attribute__ ((interrupt("ABORT")));
void Data_Abort_Handler(void)
{...}

Cytat:
A nie dało się jakoś umieścić stałych w pamięci programu pod określonym adresem?

Są umieszczone w pamięci pod określonym adresem.

Cytat:
Przy okazji: zawsze jak się ktoś o to pyta to słyszy odpowiedz że to podstawa C i jak ktoś tego nie wie to powinien się podszkolić a nie pytać o to na forum. No ale podszkalam się i podszkalam a nadal tego nie wiem. Mianowicie jak umieścić tablice stałych w pamięci programu? Najlepiej pod określonym adresem. Oczywiście stałe mają być w określonej kolejności. Na przykład jakaś tablica RGB, czyli jakiś obrazek.

Nie wiem jakie ma zastosowanie ustawienie danych pod konkretnym adresem. Ustawienie ich "po prostu" w pamięci programu jest za pomocą "const" - to chyba oczywiste.

Ustawienie pod konkretnym adresem jest bardziej skomplikowane, ale z grubsza podobne do metody jaka zastosowana jest dla tablicy wektorów.

4\/3!!
Powrót do góry
   
atom1477
Poziom 25
Poziom 25


Dołączył: 14 Lip 2005
Posty: 8068

Post#7 21 Wrz 2009 16:19   

Re: Przykładowe projekty dla ARMów


Acha. Czyli po to są później podane te elementy:
Kod:

      Reset_Handler
      Undefined_Handler
      SWI_Handler
      Prefetch_Abort_Handler
      Data_Abort_Handler
      FIQ_Handler


Chyba zaczynam rozumieć o co w tym chodzi. Dzięki.

Co do edytowania adresu to myślałem że tam jest adres obsługi (i przy okazji dziwiłem sie że jest stały). Ale to tylko przekierowanie na (zmienny) adres umieszczony później więc oczywiście nic nie trzeba edytować.

C samo w sobie nie jest jak dla mnie zaletą, ale niech będzie ;p

Ustawianie danych pod konkretnym adresem może ułatwić adresowanie. ale to jak sie pisze w assemblerze. na AVRach mocno przyspieszało działanie różnych wyżyłowanych algorytmów.

A to z const to mnie zaskoczyłeś. Zwykle takie stałe (w Delphi czy BASCOMie) nie są nigdzie umieszczane, lecz sobie po prostu są w kodzie źródłowym. A do pamięci programu trafiają w rozkazy assemblera a nie bezpośrednio jako bajt w pamięć programu.
Np:
Kod:

const a = 10;
If a < b Then



A mi chodziło o coś takiego raczej:
Kod:

db 10;



Ale jeżeli w C const załatwia te dwie rzeczy na raz to tym lepiej ;p
Powrót do góry
   
Freddie Chopin
Specjalista - Mikrokontrolery
Specjalista - Mikrokontrolery


Dołączył: 12 Gru 2005
Posty: 9841
Miasto: Zawiercie

Post#8 Post autora tematu 21 Wrz 2009 17:01   

Re: Przykładowe projekty dla ARMów


atom1477 napisał:
A to z const to mnie zaskoczyłeś. Zwykle takie stałe (w Delphi czy BASCOMie) nie są nigdzie umieszczane, lecz sobie po prostu są w kodzie źródłowym. A do pamięci programu trafiają w rozkazy assemblera a nie bezpośrednio jako bajt w pamięć programu.
Np:
Kod:

const a = 10;
If a < b Then



A mi chodziło o coś takiego raczej:
Kod:

db 10;



Ale jeżeli w C const załatwia te dwie rzeczy na raz to tym lepiej ;p

W C może być dokładnie tak samo, bo dla podanego przez ciebie przykładu umieszczanie danych w pamięci, a nie bezpośrednio w rozkazie, nie ma najmniejszego sensu z punktu widzenia optymalizacji - używasz jedynie wartości, więc użycie tej wartości, a nie konkretnej komórki pamięci (którą trzeba adresować, odczytywać itp.), jest szybsze, mniejsze i wygodniejsze.

Jeśli wg kompilatora będzie potrzeba wstawienia zmiennej fizycznie w pamięć (gdy np gdzieś używasz ich adresu, albo odwołanie znajduje się w innej jednostce kompilacji niż definicja), to kompilator zrobi to co trzeba...

4\/3!!
Powrót do góry
   
atom1477
Poziom 25
Poziom 25


Dołączył: 14 Lip 2005
Posty: 8068

Post#9 21 Wrz 2009 17:45   

Re: Przykładowe projekty dla ARMów


No mam nadzieję że umieści. Bo ja najprędzej nigdzie w kodzie nie użyję tego tak normalnie.
Jedynie pobiorę adres takiej tablicy i będę ją kopiował do RAMu (a i to pewnie w assemblerze a nie wiem czy to może nie zmyli kompilatora).
Na szczęście nie zamierzam korzystać z jakiejkolwiek optymalizacji więc może kompilator się zlituje nademną i to umieści.
Powrót do góry
   
Freddie Chopin
Specjalista - Mikrokontrolery
Specjalista - Mikrokontrolery


Dołączył: 12 Gru 2005
Posty: 9841
Miasto: Zawiercie

Post#10 Post autora tematu 21 Wrz 2009 22:34   

Re: Przykładowe projekty dla ARMów


Dobra, zrozumiałem swój błąd <:

Może taka tablica wektorów - też jest w C <:

Kod:

static void __vectors(void) __attribute__ ((used, naked, section(".vectors")));
static void __vectors(void)
{
   asm volatile(
      " ldr   pc, Reset_Vector         \n"   // "Reset" vector
      " ldr   pc, Undefined_Vector      \n"   // "Undefined instruction" vector
      " ldr   pc, SWI_Vector            \n"   // "Software interrupt (SWI)" vector
      " ldr   pc, Prefetch_Abort_Vector   \n"   // "Prefetch Abort (instruction fetch memory abort)" vector
      " ldr   pc, Data_Abort_Vector      \n"   // "Data Abort (data access memory abort)" vector
      "   .word    0                  \n"   // Reserved vector (code signature)
      " ldr   pc, [pc, #-0xFF0]         \n"   // "IRQ" vector
      " ldr   pc, FIQ_Vector            \n"   // "FIQ (fast interrupt)" vector

      " Reset_Vector:                  "
      "   .word   Reset_Handler         \n"   // Reset
      " Undefined_Vector:               "
      "   .word   Undefined_Handler      \n"   // Undefined instruction
      " SWI_Vector:                  "
      "   .word   SWI_Handler            \n"   // Software interrupt (SWI)
      " Prefetch_Abort_Vector:         "
      "   .word   Prefetch_Abort_Handler   \n"   // Prefetch Abort (instruction fetch memory abort)
      " Data_Abort_Vector:            "
      "   .word   Data_Abort_Handler      \n"   // Data Abort (data access memory abort)
      " FIQ_Vector:                  "
      "   .word   FIQ_Handler            \n"   // FIQ (fast interrupt)
   );
}


Wszystko widać, łatwo zmienić, żadnych kosmosów, działa na każdym poziomie optymalizacji itp.
__________________________________

Zaktualizowaną wersję przykładu dla LPC2103 wrzuciłem na stronę. Zmieniłem tablicę wektorów na taką jak widać wyżej, dodałem komentarz z wektorem IRQ dla dwóch różnych typów LPC (nowych i starych), oraz drobne kosmetyczne poprawki w funkcji __Default_Handler(), która obecnie jest z atrybutem "noreturn".

4\/3!!
Powrót do góry
   
atom1477
Poziom 25
Poziom 25


Dołączył: 14 Lip 2005
Posty: 8068

Post#11 21 Wrz 2009 23:22   

Re: Przykładowe projekty dla ARMów


A, o to Ci chodziło. O to żeby plik miał rozszerzenie „c” a nie „s”. NO to w takim razie to już ma sens, bo słyszałem że z plikami „s” czasami są problemy w C. A może to chodziło o pliki „asm”?

Zmiana tego jednego adresu (rejestru VicVectAddr) rozwiązała problem przerwań. Wielkie dzięki. Jak byś pomagał dla punktów to być Ci chyba przekazał wszystkie ;p
Miałem pewne problemy, nawet duże, ale na szczęście pojawiły się po poprzednim uruchomieniu przerwań czyli przynajmniej miałem pewność że przerwania już wiem jak uruchomić. A winne było jak zwykle PLL. Nie wiem co jest nie tak. Znowu nie działa. Procesor się zatrzymuje na pętli oczekującej na załapanie PLL. To znaczy raczej nie tyle się zatrzymuje, co chodzi dalej, ale PLL nie załapuje.

Freddie Chopin: piszesz trochę w assemblerze ARM? To znaczy tak więcej, bo jakieś tam małe ilości to na pewno, bo masz to choćby w startupie. Chodzi mi na przykład o jakieś algorytmy do obróbki obrazu (od razu mówię że nie chcę gotowców ;p).
Powrót do góry
   
Freddie Chopin
Specjalista - Mikrokontrolery
Specjalista - Mikrokontrolery


Dołączył: 12 Gru 2005
Posty: 9841
Miasto: Zawiercie

Post#12 Post autora tematu 21 Wrz 2009 23:27   

Re: Przykładowe projekty dla ARMów


używasz skrótów do GDB które są w najnowszym przykładzie? Komendy do OpenOCD wyłączają profilaktycznie PLL i MAM po resecie. Bez tego miałem dokładnie taki sam problem jak opisujesz (oraz kilka innych, jeszcze bardziej kosmicznych).

Assemblera znam niezbyt wiele, zwykle nie ma się po co go uczyć, bo nikłe szanse abyś był lepszy niż kompilator w 99% przypadków. Im bardziej procesor skomplikowany, tym kompilator lepszy (bo potrafi uwzględnić czynniki, o których nawet nie śniło się zwykłym ludziom).

4\/3!!
Powrót do góry
   
Google


Google Adsense


Post# 21 Wrz 2009 23:27   





Powrót do góry
   
atom1477
Poziom 25
Poziom 25


Dołączył: 14 Lip 2005
Posty: 8068

Post#13 21 Wrz 2009 23:36   

Re: Przykładowe projekty dla ARMów


Nie. Wciąż jadę na starych przykładach i zmieniłem w nich tylko ten adres.
Dodatkowo kilkanaście razy przekompilowywałem kod i wgrywałem go do procesora i działał. Po którymś przeprogramowaniu raptem przestał. I teraz jak już wiem o co chodzi to jadę na kodzie bez PLL.

Po za tym to zawsze muszę dwa razy przeprogramować. Po pierwszym przeprogramowaniu procesor nie wstaje (tzn. nie uruchamia programu - programowanie działa). Odłączam kabel od programatora, zwieram VCC do GND na kilka sekund żeby mieć pewność że procesor się zresetuje (oczywiście po wcześniejszym odłączeniu zasilania). Nie, muszę przeprogramować drugi raz (nawet mogę bez odłączania zasilania. Po prostu dwa razy i dopiero odłączyć zasilanie) i dopiero wstaje. I tak było jak jeszcze PLL działało i teraz jest tak samo.
Tak samo mam ze wszystkimi procesorami LPC2478. Zawsze kilkadziesiąt programowań przechodzi gładko, a później trzeba po dwa. A może po prostu programowanie nie idzie bezbłędnie i dlatego trzeba „poprawiać”? Tylko że przed każdym programowaniem jest kasowanie więc taka naprawa zawartości pamięci i tak by nic nie dała.


Co do assemblera. Trzeba strasznie znać się na C żeby napisać taki kod który potem zostanie mocno zoptymalizowany przez kompilator.
Mi chodzi na przykład o szybką konwersję RGB-->YCrCb.
Coś czuję że szybciej wyjdzie mi to w assemblerze.
Oczywiście będzie ciężko, bo w ARMach na czas wykonywania się programu wpływa też sekwencja rozkazów a nie osobne czasy wykonywania się każdego rozkazu. Gdzieś wyczytałem że na przykład rozkaz NOP może w ogóle nie zająć żadnego cyklu, bo zostanie wchłonięty pomiędzy jakieś dwie dłuższe instrukcje i zginie gdzieś w środku potoku.
Ale specjalnie na assemblera się nie porywam. Jak na razie faktycznie w C pisze się mi dość wygodnie. Ma problemy ze zrozumieniem pewnych rzeczy (szczególnie jak analizuje nie swój kod), ale jeszcze nie trafiłem na coś czego nie można zrobić. A w innych językach to owszem. A jeszcze jak stopień optymalizacji faktycznie będzie taki wysoki to już na pewno assemblerem się nie zajmę ;p
Powrót do góry
   
Freddie Chopin
Specjalista - Mikrokontrolery
Specjalista - Mikrokontrolery


Dołączył: 12 Gru 2005
Posty: 9841
Miasto: Zawiercie

Post#14 Post autora tematu 22 Wrz 2009 07:27   

Re: Przykładowe projekty dla ARMów


atom1477 napisał:
Nie. Wciąż jadę na starych przykładach i zmieniłem w nich tylko ten adres.
Dodatkowo kilkanaście razy przekompilowywałem kod i wgrywałem go do procesora i działał. Po którymś przeprogramowaniu raptem przestał. I teraz jak już wiem o co chodzi to jadę na kodzie bez PLL.

Po za tym to zawsze muszę dwa razy przeprogramować. Po pierwszym przeprogramowaniu procesor nie wstaje (tzn. nie uruchamia programu - programowanie działa). Odłączam kabel od programatora, zwieram VCC do GND na kilka sekund żeby mieć pewność że procesor się zresetuje (oczywiście po wcześniejszym odłączeniu zasilania). Nie, muszę przeprogramować drugi raz (nawet mogę bez odłączania zasilania. Po prostu dwa razy i dopiero odłączyć zasilanie) i dopiero wstaje. I tak było jak jeszcze PLL działało i teraz jest tak samo.
Tak samo mam ze wszystkimi procesorami LPC2478. Zawsze kilkadziesiąt programowań przechodzi gładko, a później trzeba po dwa. A może po prostu programowanie nie idzie bezbłędnie i dlatego trzeba „poprawiać”? Tylko że przed każdym programowaniem jest kasowanie więc taka naprawa zawartości pamięci i tak by nic nie dała.

Brzmi kosmicznie, więc może to być efekt MAM albo PLL - spróbuj skrótów do GDB z najnowszej wersji przykładów - powinno pomóc, jeśli nie całkiem, to choć częściowo. Jednym z efektów tych "cudów" było to, że procek pracuje źle, tak jakby wykonywał jakieś złe rozkazy, więc znów brzmi jak Twój opis. Z PLL nie warto rezygnować, tak samo z MAM, ale warto po resecie upewnić się, że faktycznie są wyłączone [;

Cytat:
Co do assemblera. Trzeba strasznie znać się na C żeby napisać taki kod który potem zostanie mocno zoptymalizowany przez kompilator.
Mi chodzi na przykład o szybką konwersję RGB-->YCrCb.
Coś czuję że szybciej wyjdzie mi to w assemblerze.
Oczywiście będzie ciężko, bo w ARMach na czas wykonywania się programu wpływa też sekwencja rozkazów a nie osobne czasy wykonywania się każdego rozkazu. Gdzieś wyczytałem że na przykład rozkaz NOP może w ogóle nie zająć żadnego cyklu, bo zostanie wchłonięty pomiędzy jakieś dwie dłuższe instrukcje i zginie gdzieś w środku potoku.
Ale specjalnie na assemblera się nie porywam. Jak na razie faktycznie w C pisze się mi dość wygodnie. Ma problemy ze zrozumieniem pewnych rzeczy (szczególnie jak analizuje nie swój kod), ale jeszcze nie trafiłem na coś czego nie można zrobić. A w innych językach to owszem. A jeszcze jak stopień optymalizacji faktycznie będzie taki wysoki to już na pewno assemblerem się nie zajmę ;p

Nie jest tak źle - wbrew pozorom jak starasz się optymalizować kod w C na siłę, to potem:
a. nie wiadomo o co chodzi,
b. kompilator nie potrafi tego zoptymalizować bardziej.

Prosty i przejrzysty kod zwykle jest zoptymalizowany wystarczająco [;

"Premature optimization is the root of all evil" - warto poczytać w necie o tej frazie, bo można spojrzeć na sprawę z innej perspektywy [;

4\/3!!
Powrót do góry
   
Google


Google Adsense


Post# 22 Wrz 2009 07:27   





Powrót do góry
   
albertb
Poziom 23
Poziom 23


Dołączył: 04 Maj 2004
Posty: 2962
Miasto: Nowy Targ

Post#15 22 Wrz 2009 09:45   

Re: Przykładowe projekty dla ARMów


Freddie Chopin napisał:
Swoją drogą chętnie poznam opinię na temat tak trickowej realizacji tablicy wektorów [;


Ta nowa wersja jest lepsza, ale przejście na C miałoby w/g mnie sens wtedy, gdybyś poszedł za ciosem i wyeliminował startup.s. Inaczej to sztuka dla sztuki.

Albert
Powrót do góry
   
Freddie Chopin
Specjalista - Mikrokontrolery
Specjalista - Mikrokontrolery


Dołączył: 12 Gru 2005
Posty: 9841
Miasto: Zawiercie

Post#16 Post autora tematu 22 Wrz 2009 09:50   

Re: Przykładowe projekty dla ARMów


albertb napisał:
Ta nowa wersja jest lepsza

Chyba nikt nie lubi skompilowanej postaci assemblera <: Niezły kosmos stworzyłem <: Dobrze że dla STM32 nie trzeba takich kombinacji...

Cytat:
przejście na C miałoby w/g mnie sens wtedy, gdybyś poszedł za ciosem i wyeliminował startup.s. Inaczej to sztuka dla sztuki.

To jest w planie dla kolejnej wersji - 1.2.0 <;

4\/3!!
Powrót do góry
   
markosik20
Poziom 22
Poziom 22


Dołączył: 27 Mar 2003
Posty: 2119
Miasto: Będzin

Post#17 22 Wrz 2009 10:44   

Re: Przykładowe projekty dla ARMów


atom1477 napisał:
Po za tym to zawsze muszę dwa razy przeprogramować. Po pierwszym przeprogramowaniu procesor nie wstaje (tzn. nie uruchamia programu - programowanie działa).


No widzę że nie tylko ja tak mam :wink:.. Z braku czasu i trochę lenistwa nie drążyłem tematu i nie szukałem przyczyny takiego zachowania.
Powrót do góry
   
Freddie Chopin
Specjalista - Mikrokontrolery
Specjalista - Mikrokontrolery


Dołączył: 12 Gru 2005
Posty: 9841
Miasto: Zawiercie

Post#18 Post autora tematu 22 Wrz 2009 11:07   

Re: Przykładowe projekty dla ARMów


No to spróbujcie skrótów do GDB które są w najnowszej wersji przykładu do LPC2103 - myślę, że powinny naprawdę pomóc choć trochę! Aktualnie nawet na liście OpenOCD ten temat jest "na tapecie", więc im więcej doświadczeń tym lepiej.

4\/3!!
Powrót do góry
   
atom1477
Poziom 25
Poziom 25


Dołączył: 14 Lip 2005
Posty: 8068

Post#19 22 Wrz 2009 11:52   

Re: Przykładowe projekty dla ARMów


No to zaraz spróbuję.
Niestety widzę na zagranicznych forach że nie tylko ja mam problemy z tym procesorem. Czyli potwierdza się moja teza że jednak jakieś błędy w krzemie procesor ma.

CO do podwójnego programowania to może chodzi o to że podczas pierwszego programowania PLL jest włączone i się nie do końca programuje?
Potem się zawiesza bo wykonuje jakieś krzaki.. Ale da się zaprogramować (już bez PLL bo procesor krzakami PLL nie uruchomi)i drugie programowanie działa.
Ale dlaczego taki efekt występuje każe gdy nie korzystam z PLL?

Z PLL nie tylko nie warto korzystać. ja nie mogę sobie na to pozwolić. Jak nie wyciągnę co najmniej 40...50MHz to nie mam po co zabierać się za tego ARMa.
Na razie jadę bez PLL, ale tylko dlatego że uruchamiam co się da. A na koniec i tak obowiązkowo będę chciał uruchomić PLL.

Dobra, to odezwę się za chwilę jak przetestuję nowe GDB.

Dodano po 26 [minuty]:

Nie wierzę! Działa!!! To znaczy jednokrotne programowanie. Podmieniłem tylko dwa pliki. Ten trzeci dla jtagkey nic mi nie dał bo u mnie już był taki od wigglera.

Markosik20: a Ty też jedziesz na LPC2478?
Powrót do góry
   
Freddie Chopin
Specjalista - Mikrokontrolery
Specjalista - Mikrokontrolery


Dołączył: 12 Gru 2005
Posty: 9841
Miasto: Zawiercie

Post#20 Post autora tematu 22 Wrz 2009 12:02   

Re: Przykładowe projekty dla ARMów


Didn't I tell so? <:

4\/3!!
Powrót do góry
   
atom1477
Poziom 25
Poziom 25


Dołączył: 14 Lip 2005
Posty: 8068

Post#21 22 Wrz 2009 12:24   

Re: Przykładowe projekty dla ARMów


I PLL też działa. Czyli częściowo cofam te słowa o błędach w krzemie ;p
Strasznie dziwne to zachowanie procesora ale dobrze że w końcy działa.
Powrót do góry
   
markosik20
Poziom 22
Poziom 22


Dołączył: 27 Mar 2003
Posty: 2119
Miasto: Będzin

Post#22 22 Wrz 2009 14:24   

Re: Przykładowe projekty dla ARMów


Moje Eclipse + reszta załogi (LPC2364) chyba toporne jest :wink:.
Pomysł z plikami .lunch do bezpośredniego wgrania u mnie nie funkcjonuje, więc musiałem "ręcznie" przeczytać tego xml.
Mam nadzieje że o to chodziło

Kod:
target remote localhost:3333
monitor reset
monitor soft_reset_halt
monitor mwb 0xE01FC040 0x01
monitor mwb 0xE01FC000 0
monitor mwb 0xE01FC080 0
monitor mwb 0xE01FC08C 0xAA
monitor mwb 0xE01FC08C 0x55
load


Niestety rdzeń się "wykłada":
Cytat:
275 monitor mwb 0xE01FC08C 0x55
&"monitor mwb 0xE01FC08C 0x55\n"
monitor mwb 0xE01FC08C 0x55
@"timeout waiting for SYSCOMP & DBGACK, last DBG_STATUS: 0\n"
timeout waiting for SYSCOMP & DBGACK, last DBG_STATUS: 0
@"Runtime error, file \"command.c\", line 469:\n"
Runtime error, file "command.c", line 469:
@" "
@"\n"

275^done
(gdb)
276 load
&"load\n"
load
&"Error erasing flash with vFlashErase packet\n"
276^error,msg="Error erasing flash with vFlashErase packet"
Error erasing flash with vFlashErase packet
(gdb)


U siebie muszę zrobić
Kod:
monitor reset halt
żeby w ogóle mówić o programowaniu
Powrót do góry
   
Freddie Chopin
Specjalista - Mikrokontrolery
Specjalista - Mikrokontrolery


Dołączył: 12 Gru 2005
Posty: 9841
Miasto: Zawiercie

Post#23 Post autora tematu 22 Wrz 2009 14:36   

Re: Przykładowe projekty dla ARMów


No i zgadza się, bo w pliku właśnie tak jest - bez soft_reset_halt. Zrobiłeś jakąś wariację na temat tych dwóch, a ich zawartość MUSI być różna.

Do programowania powinno być tak:

Kod:

monitor reset halt
monitor mwb 0xE01FC040 0x01
monitor mwb 0xE01FC000 0
monitor mwb 0xE01FC080 0
monitor mwb 0xE01FC08C 0xAA
monitor mwb 0xE01FC08C 0x55
load


Anyway - zasadnicze pytanie jest takie, czy tego typu uruchomienie programowania pomaga?

P.S.

podaje od razu wartość dla "debuggowania bez programowania":

Kod:

monitor reset
monitor soft_reset_halt
monitor mwb 0xE01FC040 0x01
monitor mwb 0xE01FC000 0
monitor mwb 0xE01FC080 0
monitor mwb 0xE01FC08C 0xAA
monitor mwb 0xE01FC08C 0x55


4\/3!!
Powrót do góry
   
markosik20
Poziom 22
Poziom 22


Dołączył: 27 Mar 2003
Posty: 2119
Miasto: Będzin

Post#24 22 Wrz 2009 14:50   

Re: Przykładowe projekty dla ARMów


Freddie Chopin napisał:

Anyway - zasadnicze pytanie jest takie, czy tego typu uruchomienie programowania pomaga?



U mnie w zasadzie niestety nie.
W przypadku LPC2144 wystarczy

Kod:
monitor reset halt
load


gdzie konfiguracja MAM, PLL itd. jest zrobiona w startup.s.

W LPC2364 (gdzie PLL już jest w main.c) w sumie też działa.....ale muszę dwa razy to wykonać żeby "się dobrze wgrało" .

______________________________________________________
No i się wyjaśniło....w pliku .cfg przy odpalaniu OpenOCD zamiast

Kod:

.....
.....lpc2000_v2 4000 calc_checksum
...


trzeba było zmienić na
Kod:

.....
.....lpc2000_v2 14765 calc_checksum
...


Mała zmiana i problemy znikneły jak ręką odjął.
Powrót do góry
   
Freddie Chopin
Specjalista - Mikrokontrolery
Specjalista - Mikrokontrolery


Dołączył: 12 Gru 2005
Posty: 9841
Miasto: Zawiercie

Post#25 Post autora tematu 22 Wrz 2009 15:08   

Re: Przykładowe projekty dla ARMów


1. U mnie samo "reset halt" i "load" w większości przypadków działało... do czasu gdy działać nagle przestało [; A kod różnił się jedynie tym, że main i Reset_Handler były 4 adresy dalej... Czasem działało, czasem nie, z wyłączaniem PLL i MAM przy rozpoczęciu sesji (na razie) działa zawsze.

2. Nie wiem czy zmiana którą zrobiłeś jest dobra - w końcu po resecie procesor działa na wewnętrznym oscylatorze 4MHz właśnie...

4\/3!!
Powrót do góry
   
markosik20
Poziom 22
Poziom 22


Dołączył: 27 Mar 2003
Posty: 2119
Miasto: Będzin

Post#26 22 Wrz 2009 15:24   

Re: Przykładowe projekty dla ARMów


Freddie Chopin napisał:

Nie wiem czy zmiana którą zrobiłeś jest dobra - w końcu po resecie procesor działa na wewnętrznym oscylatorze 4MHz właśnie...


Ważne że działa prawidłowo :wink:, wszak po resecie nie następuje automatyczne zerowanie wszystkiego i rdzeń sobie dalej hula na PLL....wykonywany jest tylko kod od początku.

Sprawdziłem to wszystko z PLL i bez PLL....bez problemu się z targetem można łączyć.
Powrót do góry
   
Freddie Chopin
Specjalista - Mikrokontrolery
Specjalista - Mikrokontrolery


Dołączył: 12 Gru 2005
Posty: 9841
Miasto: Zawiercie

Post#27 Post autora tematu 22 Wrz 2009 15:39   

Re: Przykładowe projekty dla ARMów


markosik20 napisał:
Ważne że działa prawidłowo :wink:, wszak po resecie nie następuje automatyczne zerowanie wszystkiego i rdzeń sobie dalej hula na PLL....wykonywany jest tylko kod od początku.

Powód jest inny. Podczas resetu wszystkie rejestry są zerowane. Tyle że jak chcesz debuggować, to JTAG resetuje procka, czeka chwile, zatrzymuje go i ustawia reejstr PC na 0 (software'owy reset). Do momentu zatrzymania rdzenia procek już włączył sobie PLL i MAM - stąd większość problemów.

4\/3!!
Powrót do góry
   
Google


Google Adsense


Post# 22 Wrz 2009 15:39   





Powrót do góry
   
markosik20
Poziom 22
Poziom 22


Dołączył: 27 Mar 2003
Posty: 2119
Miasto: Będzin

Post#28 22 Wrz 2009 15:58   

Re: Przykładowe projekty dla ARMów


Freddie Chopin napisał:
Podczas resetu wszystkie rejestry są zerowane.


Ale tylko te podstawowe r0->r14 ? Bo jeżeli tak to przecież rejestry od PLL są w przestrzeni peryferii więc PLL działa.
Powrót do góry
   
Freddie Chopin
Specjalista - Mikrokontrolery
Specjalista - Mikrokontrolery


Dołączył: 12 Gru 2005
Posty: 9841
Miasto: Zawiercie

Post#29 Post autora tematu 22 Wrz 2009 19:08   

Re: Przykładowe projekty dla ARMów


Wszystkie rejestry peryferyjne przyjmują wartości opisane w datasheecie przez "reset value" - zwykle zero. Zarówno rejestry PLL jak i MAM mają jako "reset value" wpisane zero.

Za przykład niech posłuży jakiś inny rejestr, choćby ADCR (rejestr ten NIE jest modyfikowany w kodzie wgranym do pamięci):

Kod:

Open On-Chip Debugger
> reset run
JTAG tap: lpc2103.cpu tap/device found: 0x4f1f0f0f (mfg: 0x787, part: 0xf1f0, ve
r: 0x4)
JTAG Tap/device matched
> halt
target state: halted
target halted in ARM state due to debug-request, current mode: User
cpsr: 0x80000010 pc: 0x00000138
> mdw 0xE0034000 1
0xe0034000: 00000000
> mww 0xE0034000 0xFFFFFFFF
> mdw 0xE0034000 1
0xe0034000: 0fefffff
> reset halt
JTAG tap: lpc2103.cpu tap/device found: 0x4f1f0f0f (mfg: 0x787, part: 0xf1f0, ve
r: 0x4)
JTAG Tap/device matched
srst pulls trst - can not reset into halted mode. Issuing halt after reset.
target state: halted
target halted in ARM state due to debug-request, current mode: User
cpsr: 0x80000010 pc: 0x0000012c
> mdw 0xE0034000 1
0xe0034000: 00000000
>


Domyślny stan PLLa i MAM po resecie to "wyłączony" - często są włączone z powodu opisanego w drugim poście (ostatni akapit), co powoduje problemy.

4\/3!!
Powrót do góry
   
albertb
Poziom 23
Poziom 23


Dołączył: 04 Maj 2004
Posty: 2962
Miasto: Nowy Targ

Post#30 23 Wrz 2009 09:28   

Re: Przykładowe projekty dla ARMów


atom1477 napisał:
Co do assemblera. Trzeba strasznie znać się na C żeby napisać taki kod który potem zostanie mocno zoptymalizowany przez kompilator.
Mi chodzi na przykład o szybką konwersję RGB-->YCrCb.
Coś czuję że szybciej wyjdzie mi to w assemblerze.


Polecam http://www.arm.com/documentation/books/4975.html
Zwłaszcza rozdział 5. Efficient C Programming

Albert
Powrót do góry
   
Napisz nowy temat  Odpowiedz do tematu      Strona Główna -> Forum elektroda.pl -> Mikrokontrolery Ogólne -> Mikrokontrolery ARM -> Przykładowe projekty dla ARMów
Strona 1 z 12 Idź do strony 123 ... 101112  Następny

Skok:
Podobne tematy
atmel qtouch przykładowe projekty (6)
Przykładowe kody dla CodeVisionAVR (2)
Przykładowe programy dla TMS320F2812 (2)
API dla protokołu SNMP. Przykładowe kody w C . (2)
Czym uruchamiacie projekty w C dla ATMega32 i wiekszych? (13)
Programowanie ARMów w ADA (18)
środowisko do programowania ARMów (at91sam7s) (1)
Programowanie ARMów Philipsa przez RS232 (2)
Czy można używać debuggera do ARMów z CodeBlocks ?? (1)
[STM32/LPC] - Początki ARMów, kilka wątpliwości. (27)


Administrator || Moderatorzy || Regulamin forum || Regulamin ogólny || Informacja o cookies || Reklama || Kontakt

Page generation time: 0.096 seconds

elektroda.pl temat RSS