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

do góry

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

do góry

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

SM

do góry

SM pisze:
> ...a jednak wymiękam z tym prockiem. niby wszystko OK a
> nie moge nawet zmienić pinu procka.
>
> SM
Na stronie atmela sa przykaldowe projekty!
A co do obslugi AVRStudio32 to pocztaj o Eclipse.

Pozdr
AK

do góry

AK pisze:

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

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

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.

do góry

AK pisze:
> SM pisze:
>> ...a jednak wymiękam z tym prockiem. niby wszystko OK a
>> nie moge nawet zmienić pinu procka.
>>
>> SM
> Na stronie atmela sa przykaldowe projekty!...

Niestety wszystko w C.

SM

do góry

Adam Dybkowski pisze:
> AK pisze:
>
>>> ...a jednak wymiękam z tym prockiem. niby wszystko OK a
>>> nie moge nawet zmienić pinu procka.
>
>> Na stronie atmela sa przykaldowe projekty!
>> A co do obslugi AVRStudio32 to pocztaj o Eclipse.
>
> 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.
>

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

do góry

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

do góry

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

do góry

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

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.

do góry