AVR32 - jak ruszyc z tym prockiem

...nie wiem czy poprawnie, ale coś "ruszyło"

źródło:

.text

.global _start

_start: rjmp always

always: rjmp always

asemblacja: avr32-as.exe --noexecstack -R --no-pic --no-linkrelax -march=ucr3 -o main.out main.s

linkowanie: avr32-ld.exe --oformat elf32-avr32 -m avr32elf_uc3b0256 -Ttext

0x80002000 main.out

Adres ładowania/uruchomienie 0x80002000 aby nie zadeptać bootloadera.

Chociaż nie wiem jeszcze czy powyższe jest poprawne. Ładowanie chyba przez BatchISP.

SM

...a jednak wymiękam z tym prockiem. niby wszystko OK a nie moge nawet zmienić pinu procka.

SM

SM pisze:

Na stronie atmela sa przykaldowe projekty! A co do obslugi AVRStudio32 to pocztaj o Eclipse.

Pozdr AK

AK pisze:

Tak poza tym aby nie wyważać otwartych drzwi weź na warsztat gotowy system operacyjny (np. Nut/OS). Jest tam masa sterowników, z których można korzystać (USB, serial, I2C itp). A możliwość odpalenia kilku procesów to dla niektórych i tak wisienka na torcie.

AK pisze:

Niestety wszystko w C.

SM

Adam Dybkowski pisze:

Ja nie chcę używać żadnych gotowych OS-ów. Chce mieć tylko i wyłącznie swój soft w ASMie żeby wycisnąć z procka ile się da.

Wśród przykładów Atmela wszystkie są "złożone" - nie znalazłem właśnie takiego prostego przykładu jak mój - kilka linijek w ASMie.

SM

...walczę dalej

wyczytałem że BatchISP:

- kasuje flash pomijając bootloader

- programuje flash nadpisując bootloader więc trzeba go dołączyć do swojego programu.

zgrałem go więc (flash od adresu 0x80000000 do 0x80001FFF) dołączyłem jak BIN do swojego źródła - nie działa:

.equ GPIO_BASE, 0xFFFF1000 .equ GPIO_GPERS, 0x04 .equ GPIO_ODERS, 0x44 .equ GPIO_OVRS, 0x54

.macro mov.w rd, imm mov \rd, LO(\imm) orh \rd, HI(\imm) .endm

.text

.global _start

_start: .incbin "isp.bin" // 8192bytes (saved flash from 0x0000 to 0x1FFF)

program_start: mov.w R0, GPIO_BASE

mov.w R1, (1 << 3) st.w R0[GPIO_GPERS], R1

mov.w R1, (1 << 3) st.w R0[GPIO_ODERS], R1

mov.w R1, (0 << 3) st.w R0[GPIO_OVRS], R1

always: rjmp always

_stop:

zgrałem jeszcze raz pomijając dwa pierwsze bajty i wstawiając tam "trampoline" - nie działa:

.equ GPIO_BASE, 0xFFFF1000 .equ GPIO_GPERS, 0x04 .equ GPIO_ODERS, 0x44 .equ GPIO_OVRS, 0x54

.macro mov.w rd, imm mov \rd, LO(\imm) orh \rd, HI(\imm) .endm

.text

.global _start

_start: rjmp program_start

.incbin "isp.bin" // 8190bytes (saved flash from 0x0002 to 0x1FFF)

program_start: mov.w R0, GPIO_BASE

mov.w R1, (1 << 3) st.w R0[GPIO_GPERS], R1

mov.w R1, (1 << 3) st.w R0[GPIO_ODERS], R1

mov.w R1, (0 << 3) st.w R0[GPIO_OVRS], R1

always: rjmp always

_stop:

asemblacja: avr32-as.exe -R -march=ucr1 -o main.out main.s

linkowanie: avr32-ld.exe --oformat ihex -m avr32elf_uc3b0256 -Ttext 0x80000000 -Tbss

0x00000000 -o main.hex main.out

programowanie: batchisp -device at32uc3b0256 -hardware usb -operation erase f memory flash blankcheck loadbuffer main.hex program verify start reset 0

BatchISP pisze że programuje, weryfikuje, wszystko OK, a i tak pin PA3 nie chce przyjąć poziomu niskiego. (Pomijam już to, że flash jest od 80000000 a BatchISP wszystko pokazuje od 0). Generuje plik HEX od 80002000, BatchISP i tak ładuje od 0. No i teraz nie wiem co właściwie to zero oznacza. Ale gówno.

No to zabrałem się za prosty przykład z AVR Studio - sterowanie wyjście. Załadowałem. Działa. Chciałem podejrzeć co gdzie sie ładuje. Przerabiam ELF na HEX poprzez ObjCopy - wywala błąd!

Ale syf. Powoli wymiękam. Robiłem już na chyba 8 różnych rodzinach procków (od 8bit do ARMów) ale takiego problemu z uruchomieniem to jeszcze nie miałem!

SM

MAM! DZIAŁA!

Dla zainteresowanych podaję przepis na uruchomienie AT32UC3B0256 bez całego zbędnego "bagażu".

1. Programem BatchISP zgrać bootloader (potrzebny gdy programujemy używając BatchISP poprzez USB - zawsze zadeptuje bootloader nie uwzględniając adresów ładowania):

batchisp -device at32uc3b0256 -hardware usb -operation erase f memory flash addrange 0x0 0x01FFF read savebuffer "C:\isp.hex" hex386

1. Programem Hex2Bin przerobić "isp.hex" na "isp.bin"

1. Napisać prosty program, np. taki jak poniżej (generowanie przebiegu prostokątnego na PA3): Zapisać pod nazwą "main.s".

.equ GPIO_BASE, 0xFFFF1000 .equ GPIO_GPERS, 0x04 .equ GPIO_ODERS, 0x44 .equ GPIO_OVR, 0x50

.text

.global _start

_start: .incbin "isp.bin"

program_start: // init

mov R0, LO(GPIO_BASE) orh R0, HI(GPIO_BASE) mov R1, (1 << 3) st.w R0[GPIO_GPERS], R1 mov R1, (1 << 3) st.w R0[GPIO_ODERS], R1

// pętla

main_loop:

// zerowanie PA3

mov R1, (0 << 3) st.w R0[GPIO_OVR], R1

// opóźnienie

mov R2, 1000 del1: sub R2, R2, 1 brne del1

// ustawienie PA3

mov R1, (1 << 3) st.w R0[GPIO_OVR], R1

// opóźnienie

mov R2, 1000 del2: sub R2, R2, 1 brne del2

// powrót do pętli

rjmp main_loop

_stop:

1. Asemblacja poprzez:

avr32-as.exe -R -march=ucr1 -o main.out main.s

1. Linkowanie poprzez:

avr32-ld.exe --oformat ihex -m avr32elf_uc3b0256 -Ttext 0x80000000 -Tbss

0x00000000 -o main.hex main.out

1. Ładowanie do procka poprzez:

batchisp -device at32uc3b0256 -hardware usb -operation erase f memory flash blankcheck loadbuffer main.hex program verify start reset 0

Po załadowaniu program sam się uruchomi. Będzie się także uruchamiał po resecie. Aby znów zaprogramować procek należy zewrzeć do masy PA13 i zresetować go - wejdzie do bootloadera (programowania ISP poprzez USB).

SM

SM pisze:

Ale coś się tak uczepił asemblera. Istnieje przecież na świecie kompilator gcc - czyli bez dodatkowych wydatków można pisać programy w C. To nie PIC w końcu. No a program napisany w C/C++ zawsze w przyszłości będziesz mógł łatwo przenieść np. na bardziej wydajną platformę. Po co zawracać sobie głowę asemblerem właściwie (tzn. znać warto aby rozumieć, co wyprodukował kompilator - ale nie warto pisać samemu w asm).

Bo dla mnie ważna jest szybkość procka. W ASMie sam mogę dobrać sobie każdą instrukcję, najbardziej optymalną, nie ma zbędnych "dodatków" jakie generuje kompilator. Żaden kompilator języka wysokiego poziomu nie da tak wydajnego kodu jak pisanie samemu w ASMie.

Osiągi jakie ma AVR32 idealnie mi pasują. Do tej pory robiłem na ARMach Atmela, Philipsa, Analoga i brakowało mi wielu rzeczy jakie ma AVR32 (np. sprzętowego szybkiego dzielenia). Spośród procków mających kilkadziesiąt MIPSów i będących w cenie AVR32, to te wypadają najlepiej.

Przy dużych projektach robię tak, że procedurki pisze w ASMie (przede wszystkim przerwania) a potem łącze to w logiczną całość w C. Wtedy mam idealne jak dla mnie rozwiązanie - w miarę szybkie (dzięki ASM) a jednocześnie logicznie przejrzyste działanie programu jakie daje język wysokiego poziomu.

Fajne były ARMy Atmela SAM7S ale okazało się że mają problemy ze startem przy zbyt wolnym narastaniu napięcia zasilającego. Po prostu nie startował. Zależało mi na procku który ma zewnętrzny reset, abym mógł mocno filtrowac napięcie zasilania (układ pracuje w mocno zakłóconym środowisku), i puścić go kiedy będzie już można do tego sprzętowe dzielenie. SAM7S tego nie miały.

SM

Jedno bynajmniej nie wyklucza drugiego. Apropo OS'a: Typow implementacja watkow we wlasnym, wycisnietym sofcie ->

Odpytywanie non-stop wszystkich pocedurek czy czasem ktoras nie ma czegos do zrobienia - jakiez to szybkie i wydajne;) Wszak przeciez scheduler to diabel wcielony, ktory zzera nasze cene zasoby a nasza "petla glowna" nie.

Taaaa. Moze pora "wlaczyc" optymalizacje w kompilatorze ;)

Poeksperymentuj - gcc czesto jest 'dosc' pomyslowy. Mi sie juz od kilku lat nie kalkuluje czasowo pisanie w ASM. Jedynie krytyczne czasowo przerwania pisze w ASM (a i to staram sie to ograniczyc do wrzucenia danej do kolejki do dalszego przetwarzania w C).

AVR32 (na pewno UC3A0512) ma to samo - jak za wolno napiecie narasta to procek sie zatrzaskuje i grzeje, wiec uwazaj. W pdfie nigdzie o tym nie znalazlem.

SM pisze:

No to pościgaj się z gcc. Duet kompilator+optymalizator potrafi czasami tak wymyślić sekwencję instrukcji, dodatkowo ze zmienioną kolejnością, że w ASM musiałbyś długo siedzieć i kombinować, czy W OGÓLE da się to napisać jeszcze optymalniej. A biorąc pod uwagę czas zużyty na pisanie programu (czyli kasa w firmie na to wydana) - to ASM jest kompletnie nieopłacalny. Dolicz jeszcze czas usuwania błędów z tysięcy linii kodu w asemblerze, brrrr.

No to może trochę się nim pobawie. Tak z ciekawości zobaczę jaki kod mu wyjdzie z włączona na maksa optymalizacją. Tym bardziej że muszę napisać sobie obsługę USB-CDC w ASMie. Raz już pisałem dla SAM7S, teraz muszę ją przepisać na AVR32. Zobacze jak to wyjdzie w ASM i GCC.

Mam taką metodę pisania programów że błędy raczej mi się nie zdarzają, więc ASM to nie problem.

SM

Nieee. Tylko nie to! A czy pomaga zewnętrzny reset? Zewnętrzny układ który trzyma reset procka, zamiast jego wewnętrznego brownout. Może tylko jego wewnętrzny układ kontroli napięcia działa niepoprawnie? Może na zewnętrznym resecie będzie OK?

Ale byłby numer jakby znów wpakował się w atmela co zastartować nie potrafi. Zaraz zrobię testy.

SM

Zawsze będzie wolniej. Nawet pomijając osługę zdarzeń, semaforów, mutexów, czyli robiąc w przerwaniu tylko obsługę przełączania wątków, to sama ta obsługa przełączania zajmuje czas. Trzeba do kontekstu zapisać stan bierzącego wątku i odtworzyć stan kolejnego wątku z tablicy. Tym bardziej że ja potrzebuję akurat w przerwaniu wywoływanym z częstotliwością kilkuset herzów liczyć trajektorię dla

4 osi silników wraz z zachowaniem trapezowego profilu prędkości.

SM

SM pisze:

Zrobiłem szybki test. Bardzo wolno podawałem na LDO (obniża napięcie z 5V do 3,3V dla procka) napięcie od 0 to 5V. Procek zastartował poprawnie. Oczywiście ostateczne potwierdzenie wyjdzie dopiero w kompletnym docelowym układzie - główne zasilanie odkłócone przez filtr LC, podpięte do procka pozostałe elementy (np. mały CPLD). Może być tak że coś "zbiera" przez zabezpieczenia przepięciowe wejść i podaje to sobie gdzieś wewnątrz na zasilanie i głupieje bo brownout czy reset tego nie widzi. Każda nóżka dostaje różne napięcia w różnym czasie. Niektóre te same 3V3 które ma procek na VCCIO, inne 5V (np. z CPLD) które przecież narasta inaczej niż to co on widzi na 3V3 czy resecie.

SM

I to jest wlasnie clue problemu. Kto powiedzial, ze zawsze : zmierzyles, sprawdziles czy tylko tak twierdzisz bo tam jest tyle kodu???

Rescheduling jest wykonywany nie non-stop tylko gdy :

1. przyjdzie systemowe przerwanie zegarowe np. 10ms
2. w przerwaniu budzisz watek o wyzszym priorytecie niz biezacy Pamietaj, ze przelacznie watkow jest silnie zoptymalizowani i jest napisane w asemblerze - trzeba na stos zrzucic kontekst czyli w ARMie 16 rejestrow natomiast twoja petla glowna tlucze non-stop.

Wszelkie elemnty programowania wspolbieznego sa uzyte tylko wtedy gdy ich uzyjesz (same z siebie nie obciazaja systemu) a wygoda jest duza. Juz widze te wydajna synchronizacje zadan na flagach;)

Ze stosu i jest to raptem kilkadziesiat instrukcji procesora i jestes w nowym watku, procedurki na flagach zuzywaja wiecej czasu procesora - pamietaj ze sa wykonywne non-stop

A to wyjasnia wszystko - czasochlone obliczenia w procedurze obslugi przerwania. Nie twierdze, ze jest to zle w kazdym przypadku tj. gdy masz tylko jedno zadanie do wykonania to jest ok - dosc typowa sytuacja na kontrolerze. Ale w sytuacji bardziej generycznej tj. kilka zadan do obrobienia rownoczesnie JEST TO NIEACEPTOWEALNE bezwzgledu czy jest OS czy nie - responsywnosc takiego systemu jest mala.

W moim przypadku w przerwaniu realizowana jest generacja przebiegów (impulsów krok +/-) dla silników (trajektoria, modyfikacja prędkości) a główny program zajmuje się obsługą USB. Chociaż trochę się martwię o tą obsługę USB. Nie wiem czy nie będzie zbyt dużych opóźnień w odpowiedzi na komendy hosta. Czas trwania 1 bitu dla full speed to 1/12MHz = 83ns. Wg standardu USB ograniczenie czasowe nie może być mniejsze 16 bitów i większe niż 18 bitów. Jeśli procek znajduje się za 5-tym hubem to na odpowiedź mam 7,5 bitu. I to mnie trochę niepokoi.

SM