AVR32 - jak ruszyc z tym prockiem
SM
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
SM
�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
SM
nie moge nawet zmieniďż˝ pinu procka.
SM
AK
> ...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
Adam Dybkowski
>> ...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.
SM
> SM pisze:
>> ...a jednak wymiękam z tym prockiem. niby wszystko OK a
>> nie moge nawet zmienić pinu procka.
>>
>> SM
Niestety wszystko w C.
SM
SM
> 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
SM
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
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
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
Adam Dybkowski
> 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).
SM
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.
> 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ę.
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.
> 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).
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
cepu69
> 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.
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.
> >> Ale coďż˝ siďż˝ tak uczepiďż˝ asemblera.
>
> 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.
Taaaa. Moze pora "wlaczyc" optymalizacje w kompilatorze ;)
Jerry1111
>> Ale coś się tak uczepił asemblera.
>
> 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.
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).
> 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ł.
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
Adam Dybkowski
>> Ale coś się tak uczepił asemblera.
>
> 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.
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.
SM
> 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.
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.
>... 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.
>
Mam taką metodę pisania programów że błędy raczej mi się nie zdarzają,
więc ASM to nie problem.
SM
SM
> procek sie zatrzaskuje i grzeje, wiec uwazaj. W pdfie nigdzie o tym nie
> znalazlem.
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
SM
> 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.
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
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
shg
> 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).
LC na zasilaniu? Oczywiście sprawdziłeś, jak się ten filtr zachowuje
(co pojawia się na jego wyjściu) w stanach przejściowych, zwłaszcza
przy włączaniu zasilania i nagłych skokach obciążenia?
SM
>> w kompletnym docelowym uk�adzie - g��wne zasilanie odk��cone
>> przez filtr LC, podpi�te do procka pozosta�e elementy (np. ma�y
>> CPLD).
>
> LC na zasilaniu? Oczywi�cie sprawdzi�e�, jak si� ten filtr zachowuje
> (co pojawia si� na jego wyj�ciu) w stanach przej�ciowych, zw�aszcza
> przy w��czaniu zasilania i nag�ych skokach obci��enia?
Tak. Bardzo �adnie wszystko filtruje. Mia�em problemy w mocno
zak��conym �rodowisku, zak��cenia na zasilaniu, itp. Teraz
jest OK.
SM
cepu69
>> 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.
>
> Zawsze b�dzie wolniej.
I to jest wlasnie clue problemu. Kto powiedzial, ze zawsze : zmierzyles,
sprawdziles czy tylko tak twierdzisz bo tam jest tyle kodu???
> 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.
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;)
> Trzeba do kontekstu zapisa� stan bierz�cego w�tku i odtworzy� stan
> kolejnego w�tku z tablicy.
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
> 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.
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.
SM
>> z cz�stotliwo�ci� kilkuset herz�w liczy� trajektori� dla
>> 4 osi silnik�w wraz z zachowaniem trapezowego profilu pr�dko�ci.
> 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
Jerry1111
> SM pisze:
>>> 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.
>>
>> 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
>
> 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.
A napiecie za LDO roslo powoli? Bo u mnie lockup jest dosc powtarzalny -
musialem zadbac o dobre zasilanie.
Z drugiej strony - pierwszy procek Atmela jaki uzylem i dosc duza wpadka
(poza tym nie nowa - Altera to miala z 5 lat temu z Cyclonami).
--
Jerry1111
SM
Bardzo wolno. Powoli kręciłem zasilaczem od 0 do 5V.
Napięcie 5V narastało powoli, za LDO 3,3V też powoli,
napięcie 1,8V z VDDOUT powoli. Nóżka reset bez zewnętrznego
układu reset (rezystor 10k, kondensator 100nF, dioda BAS85
równolegle do rezystora). Na resecie napięcie też narastało
powoli. Procek za każdym razem prawidłowo startuje.
(używam 32UC3B0256).
> Z drugiej strony - pierwszy procek Atmela jaki uzylem i dosc duza wpadka
> (poza tym nie nowa - Altera to miala z 5 lat temu z Cyclonami).
>
Po testach z AT91SAM7S64 doszukałem się w PDFie takiego zdania:
"During startup, core supply voltage (VDDCORE) slope must be superior or
equal to 6V/ms."
Oczywiście już po tym jak gotowy prototyp i brałem się za jego
oprogramowanie :)
SM
Zbych
> 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.
A to �e host wysy�a pakiety do urz�dzenia co 1ms, to ju� ci nie
przeszkadza? Albo to, �e program na PC mo�e by� wyw�aszczony na dowolnie
d�ugi czas i nic ci nie wy�le?
SM
> przeszkadza?
A co ma jedno z drugim wsp�lnego? Przecie� pisa�em o czasie
oczekiwania na odpowied�, a nie o tym �e czas pomi�dzy
dwoma pakietami SOF to 1ms. Sk�d w takim razie
ograniczenie oczekiwania na odpowied� do 18 bit�w?
No chyba �e chodzi tu o odpowied� sprz�towego
kontrolera USB w procku, a nie mojego softu
obs�uguj�cego USB.
> Albo to, �e program na PC mo�e by� wyw�aszczony na dowolnie
> d�ugi czas i nic ci nie wy�le?
Czyli mam liczy� na to �e program obs�uguj�cy b�dzie
"przyhamowywany" i tylko dlatego soft b�dzie dzia�a�.
SM
Zbych
>> przeszkadza?
>
> A co ma jedno z drugim wsp�lnego? Przecie� pisa�em o czasie
> oczekiwania na odpowied�, a nie o tym �e czas pomi�dzy
> dwoma pakietami SOF to 1ms. Sk�d w takim razie
> ograniczenie oczekiwania na odpowied� do 18 bit�w?
> No chyba �e chodzi tu o odpowied� sprz�towego
> kontrolera USB w procku, a nie mojego softu
> obs�uguj�cego USB.
Oczywi�cie, to kontroler zajmuje si� sygnalizacj�, czy ma co� w buforze
do wys�ania, czy nie.
>> Albo to, �e program na PC mo�e by� wyw�aszczony na dowolnie
>> d�ugi czas i nic ci nie wy�le?
>
> Czyli mam liczy� na to �e program obs�uguj�cy b�dzie
> "przyhamowywany" i tylko dlatego soft b�dzie dzia�a�.
Tak to napisa�e� jakby tw�j soft musia� dostawa� nowe dane z
dok�adno�ci� co do us. Je�li tak nie jest to ok.
SM
No to chyba siďż˝ kompletnie nie rozumiemy.
Przyk�ad:
1. Host USB wysy�a do urz�dzenia pakiet "In Token"
2. Urz�dzenie USB odpowiada pakietem "Data"
3. Host USB wysy�a do urz�dzenia pakiet "Handshake"
Sterownik USB w uC informuje mnie, �e odebra� dane - czyli
pakiet "In Token". Ja te dane interpretuje i odsy�am
"Data". I pytanie - jak d�ugo Host czeka na odpowied�
od urz�dzenia?
W ksi��ce wyczyta�em:
"Czas pomi�dzy dwoma kolejnymi pakietami SOF nazywany jest
ramk�". Ramka wynosi 1ms. Czyli wnioskuj� �e Host wysy�a
pakiet "In Token" poprzedzony przez SOF. Ja odpowiadam
"Data" r�wnie� z nag��wkiem SOF, ale nie w tej samej 1ms
bo mi�dzy dwoma pakietami SOF ma by� 1ms przerwy (czyli
ramka).
Ale dalej czytam:
"St�d wyra�one w bitach maksymnalne op�nienie w dotarciu
odpowiedzi do gosta wynosi 16 bit�w. W�a�nie to op�nienie
jest podstaw� do okre�lenia ograniczenia czasowego
oczekiwania na odpowied� w urz�dzeniu nadaj�cym".
W wcze�niej:
w najgorszym przypadku przej�cie przez 5 hub�w mo�e
zaj�� 350ns. "Ostatni hub przesy�a pakiet do urz�dzenia,
kt�re po jego odebraniu i sprawdzeniu wysy�a
odpowied�. SPECYFIKACJA PODAJE, �e czas na WYMIENIONE
OPERACJE liczony od momentu dotarcia odpowiedzi do
huba [...] nie mo�e przekroczy� 7,5 bitu."
No to zaczynam nie ca�kiem rozumie� o co tu chodzi.
SM
SM
"The maximum length of a standard USB cable is 5.0 meters (16.4 ft). The
primary reason for this limit is the maximum allowed round-trip delay of
about 1500 ns. If a USB device does not answer to host commands within
the allowed time, the host considers the command to be lost."
"The USB Specification allows a maximum period of approximately 1.5
microseconds for the round-trip delay of a single communication from a
host computer to a device and back to the computer"
Je�li urz�dzenie USB nie odpowie Hostowi USB w czasie 1,5us,
Host uznaje komendďż˝ za "straconďż˝" (nie odebranďż˝).
W�a�nie tym czasem si� martwi�. W 1,5us musz� odebra� dane od
sterownika USB w uC, zanalizowa� je, i odes�a� odpowied�.
Poniewaďż˝ mogďż˝ byďż˝ za 5-tym Hubem to na wszystko pozostaje mi
7,5 bitu * 83ns (FullSpeed) 623ns!!!
SM
Zbych
> No to chyba siďż˝ kompletnie nie rozumiemy.
>
> Przyk�ad:
> 1. Host USB wysy�a do urz�dzenia pakiet "In Token"
> 2. Urz�dzenie USB odpowiada pakietem "Data"
> 3. Host USB wysy�a do urz�dzenia pakiet "Handshake"
>
> Sterownik USB w uC informuje mnie, �e odebra� dane - czyli
> pakiet "In Token". Ja te dane interpretuje i odsy�am
> "Data". I pytanie - jak d�ugo Host czeka na odpowied�
> od urz�dzenia?
Je�li nie zd��ysz wstawi� do bufora danych to kontroler wy�le
informacj�, �e nic nie ma do wys�ania. Tym steruje sprz�t, wi�c nie ma
co si� przejmowa� czy zd��ysz. Za 1ms host ponowi pytanie. Je�li wtedy
b�dzie co� w buforze, to kontroler to wy�le.
Zbych
> W�a�nie tym czasem si� martwi�. W 1,5us musz� odebra� dane od
> sterownika USB w uC, zanalizowa� je, i odes�a� odpowied�.
> Poniewaďż˝ mogďż˝ byďż˝ za 5-tym Hubem to na wszystko pozostaje mi
> 7,5 bitu * 83ns (FullSpeed) 623ns!!!
Nie musisz. Dane mog� p�j�� do hosta przy nast�pnej ramce.
SM
> informacj�, �e nic nie ma do wys�ania. Tym steruje sprz�t, wi�c nie ma
> co si� przejmowa� czy zd��ysz. Za 1ms host ponowi pytanie. Je�li wtedy
> b�dzie co� w buforze, to kontroler to wy�le.
Aaaa no to teraz jasne. Ba�em si� �e sterownik USB w uC
musi dostaďż˝ dane wtedy kiedy chce tego host, a potem
one przepadajďż˝.
Ale jak tak, no to spoko. W razie czego b�d� mia�
komunikcjďż˝ co drugďż˝ ramkďż˝ i tyle.
Dzi�ki,
SM
SM
Ale masakra.
Chyba z �adnym prockiem nie mia�em tyle
kombinowania (chocia�by ze sam� struktur�
programu �e asembler i linker poprawnie
przygotowali dane do �adowania do procka).
Skonfigurowa�em procka, ruszy�em przerwania
na timerze.
Wszystko lekko r�bni�te przez sam fakt, �e
Atmel daďż˝ flash od adresu 0x80000000 a to
w integer jest liczba ujemna! Asembler
g�upieje przy bezpo�rednim ustawieniu
sekcji org na ten adres, bo dla niego to
liczba ujemna i stwierdza �e kompilacja
odbywa si� w ujemn� stron�. Trzeba wi�c
robiďż˝ offset w linkerze. Ale tu kolejny
zgrzyt bo sta�e zdefiniowane jako r�nica
adres�w wychodz� wtedy Linkerowi b��dnie
(np. offset autoprzerwania wzgl�dem EVBA).
Ostatecznie rozwi�za�em to tak:
//
===========================================================================
// Start of data memory.
//
===========================================================================
.section .bss, "", @nobits
.org 0
stack_beg:
.skip 256
stack_end:
//
===========================================================================
// Start of program memory.
//
===========================================================================
.section .text, "ax", @progbits
.global _start
_start:
.incbin "isp.bin" // original bootloader saved from flash memory
//
===========================================================================
// Ints vectors.
//
===========================================================================
StartEVBA:
program_begin:
rjmp program_start
rjmp Int0Handler
rjmp Int1Handler
rjmp Int2Handler
rjmp Int3Handler
.equ Int0Offset, 4 >> 1
.equ Int1Offset, 8 >> 1
.equ Int2Offset, 12 >> 1
.equ Int3Offset, 16 >> 1
//
===========================================================================
// Timer 0 interrupt.
//
===========================================================================
Int0Handler:
// reset int flag
mov.w r8, TC0_BASE
ld.w r9, r8[TC_SR]
// change PA3 pin
mov.w r8, LBM_BASE
mov r9, (1 << 3)
st.w r8[LBM_OVR0T], r9
// int exit
rete
//
===========================================================================
// Program start.
//
===========================================================================
program_start:
// --- stack
mov.w sp, stack_end
****************************************************************************
i ustawiam:
// set EVBA pointer
mov.w r0, StartEVBA
mtsr SYSREG_EVBA, r0
// set autovector offset for group 14
mov.w r0, INTC_BASE
mov.w r1, Int0Offset
st.w r0[INTC_IPR0 + 4*14], r1
i oczywi�cie wszystko dzia�a, ale ile musia�em czasu straci�
�eby co� tak prostego zrobi�.
Nie mogli daďż˝ flasha od 0x40000000. Przeciez mieliby wtedy 1GB
na rozbudowďż˝ RAM i 1GB (minus rejestry) na FLASH.
SM
SM
> 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.
>
Mam zrobione USB CDC więc mogę podać "wyniki":
Całość w ASMie i jednej pętli. Program wygląda tak:
Na starcie:
Inicjalizacja procka (flahs, clock,...).
Inicjalizacja timera 0 (i przerwań).
Inicjalizacja USART.
Inicjalizacja USB.
W głównej pętli:
Obsługa USART
Obsługa USB
Program to co odbierze na USB wysyła na USART, to co
odbierze na USART wysyła na USB.
Poza główną pętla obsługa przerwania od timera 0 co 1ms
(tak dla celów testowo-poznawczych przerwań)
Całość (razem ze strukturami USB) zajęła mi 1920 bajtów.
SM
Adam Dybkowski
> Mam zrobione USB CDC więc mogę podać "wyniki":
> Całość w ASMie i jednej pętli. Program wygląda tak:
>
> Na starcie:
> Inicjalizacja procka (flahs, clock,...).
> Inicjalizacja timera 0 (i przerwań).
> Inicjalizacja USART.
> Inicjalizacja USB.
>
> W głównej pętli:
> Obsługa USART
> Obsługa USB
>
> Program to co odbierze na USB wysyła na USART, to co
> odbierze na USART wysyła na USB.
No to teraz przerób główną pętlę na przerwania aby program mógł robić
też coś pożytecznego. Bo zniżenie całego procka AVR32 do roli konwertera
USB-RS232 to dla niego zniewaga. :)
SM
> też coś pożytecznego. Bo zniżenie całego procka AVR32 do roli konwertera
> USB-RS232 to dla niego zniewaga. :)
Oczywiście nie ma sprawy, aby wrzucić to w przerwanie czy też
obsłużyć na dodatkowym tasku, ale ja właśnie mam potrzebę
aby główna pętla zajmowała się "mniej ważnymi" operacjami
(jak np. transmisja z USB), a najważniejsza część programu
będzie wywoływana co dokładnie odmierzany czas - czyli przerwaniu.
Przygotowałem sobie także "środowisko" aby pisać soft
na procka w C+ASM. Korzystam z edytora ConTEXT i
środowiska GCC.
Te AVR32 spodobały mi się na tyle, że chyba dłużej przy nich
zabawię. Przyznaję że wzięła mnie już ochota na stworzenie
własnego środowiska i kompilatora dla niego. No chyba że
zagłębie się w źródła gcc i go przerobię tak, aby
generował kod wynikowy bardziej podobny do sposobu w jaki
pisze w asm-ie (chodzi mi przede wszystkim o sposób
dostępo do zmiennych globalnych w SRAM. Kompilator
używa lddpc, a ja zwykłego ld i adresowanie pośrednie
z przesunięciem - poświęcam na to jeden rejestr r7.
adresuję r7[adres_zmiennej] - offset jest 16bit więc
wystarcza na całe 32KB SRAM. No chyba że jest jakaś
opcja gcc która coś takiego potrafi wymusić).
Jeszcze się trochę przyjrzę jaki kod generuje gcc.
Ale same AVR32 zaczynają mi się niezmiernie podobać.
Mam pomysł na większy (jak sądzę bardzo ciekawy)
projekt, ale muszę gdzieś dorwać kilka AT32UC3A3128
w jakiejś rozsądnej cenie.
Pozdrawiam,
SM
SM
> też coś pożytecznego. Bo zniżenie całego procka AVR32 do roli konwertera
> USB-RS232 to dla niego zniewaga. :)
Oczywiście nie ma sprawy, aby wrzucić to w przerwanie czy też
Artur M. Piwko
SM <bi...@korinsj.com.pl> screamed:
> Poza główną pętla obsługa przerwania od timera 0 co 1ms
> (tak dla celów testowo-poznawczych przerwań)
>
> Całość (razem ze strukturami USB) zajęła mi 1920 bajtów.
>
Rozmiar nie jest tak istotny, jak czas, który zajęło pisanie.
--
[ Artur M. Piwko : Pipen : AMP29-RIPE : RLU:100918 : From == Trap! : SIG:223B ]
[ 19:41:16 user up 12266 days, 7:36, 1 user, load average: 0.97, 0.71, 0.02 ]
APATHY ERROR: Don't bother striking any key.
SM
> Rozmiar nie jest tak istotny, jak czas, który zajęło pisanie.
>
Rozgryzanie procka - 3dni.
USB-CDC - 2dni.
Więc pryszcz, biorąc pod uwagę to że będę używał tej samej
mojej procedury USB-CDC w wielu projektach.
Cała obsługa USB-CDC jest niewielka - 460 linii. Pisania
dużo nie było. Gorzej z rozgryzaniem procka.
W wolnej chwili zrobię mu test szybkości. Zakupiłem
DAC stereo 16bit i zobaczę czy wyrobi się w roli
syntezatora FM (emulacja Yamahy DX-7). Jak da radę
z polifonią przynajmniej 8 to robię sobie kompletny
syntezator na dwóch AVR32 i SDRAMie.
SM