AVR32 - jak ruszyc z tym prockiem

Fri Nov 06, 2009 3:59 pm   

Witam,

Czy ktoś z obecnych tu bawił się juz prockami AVR32?
Mam u siebie AT32UC3B0256 i nie mogę z nim zacząć.

AVR32 Studio - nie wiem jak utworzyć prosty projekt
- jeden plik w asemblerze do skompilowania, aby
uzyskać gotowy plik do załadowania do procka poprzez
bootloader po USB.

No to powalczyłem z konsoli z avr32-as:

.org 0x80000000

always:
rjmp always

i nie łyka - wypisuje błąd że adresu org (wcale mnie
to nie dziwi bo 0x80000000 na 32-bit ze znakiem
jest przecież ujemne).

W PDF jest:
- SRAM od 0x00000000, wielkość 32KB
- FLASH od 0x80000000, wielkość 256KB

Czy ktoś może pomóc jak coś tak prostego ruszyć?

Przećwiczyłem już wiele ARMów (Atmela, Analoga, Philipsa)
i nigdy nie miałem takich problemów jak z tym AVR32.

Pozdrawiam,
SM

Fri Nov 06, 2009 5:07 pm   

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

Sat Nov 07, 2009 12:45 pm   

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

SM

Sat Nov 07, 2009 2:36 pm   

SM pisze:

A co do obslugi AVRStudio32 to pocztaj o Eclipse.

Pozdr
AK

Sat Nov 07, 2009 11:22 pm   

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.

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

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

Sun Nov 08, 2009 6:33 am   

AK pisze:

Niestety wszystko w C.

SM

Sun Nov 08, 2009 6:34 am   

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

Sun Nov 08, 2009 8:13 am   

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

Sun Nov 08, 2009 8:53 am   

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

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

3. 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:

4. Asemblacja poprzez:

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

5. Linkowanie poprzez:

avr32-ld.exe --oformat ihex -m avr32elf_uc3b0256 -Ttext 0x80000000 -Tbss
0x00000000 -o main.hex main.out

6. Ł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

Sun Nov 08, 2009 9:16 pm   

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

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

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

Mon Nov 09, 2009 5:51 am   

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

Mon Nov 09, 2009 7:16 pm   

SM wrote:


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.

Mon Nov 09, 2009 11:04 pm   

SM wrote:

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.


--
Jerry1111

Mon Nov 09, 2009 11:53 pm   

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.

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

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

Tue Nov 10, 2009 6:20 am   

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