AVR32 AT32UC3B0256 - jak stworzyć prosty projekt w AVR32 Studio i skompilować kod?

Tue Nov 10, 2009 6:22 am   

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

Tue Nov 10, 2009 6:28 am   

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

Tue Nov 10, 2009 6:36 am   

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

Tue Nov 10, 2009 9:50 am   

shg pisze:

Tak. Bardzo ładnie wszystko filtruje. Miałem problemy w mocno
zakłóconym środowisku, zakłócenia na zasilaniu, itp. Teraz
jest OK.

SM

Tue Nov 10, 2009 10:37 am   

On 10 Lis, 06:36, SM <bi...@korinsj.com.pl> wrote:

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?

Tue Nov 10, 2009 5:31 pm   

SM wrote:


sprawdziles czy tylko tak twierdzisz bo tam jest tyle kodu???


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


nowym watku, procedurki na flagach zuzywaja wiecej czasu procesora -
pamietaj ze sa wykonywne non-stop


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.

Tue Nov 10, 2009 9:42 pm   

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

Tue Nov 10, 2009 11:36 pm   

SM wrote:

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

Wed Nov 11, 2009 9:38 am   

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


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

Wed Nov 11, 2009 11:53 am   

SM przemówił ludzkim głosem:


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?

Wed Nov 11, 2009 12:29 pm   

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.


Czyli mam liczyć na to że program obsługujący będzie
"przyhamowywany" i tylko dlatego soft będzie działał.

SM

Wed Nov 11, 2009 1:59 pm   

SM przemówił ludzkim głosem:

Oczywiście, to kontroler zajmuje się sygnalizacją, czy ma coś w buforze
do wysłania, czy nie.


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.

Wed Nov 11, 2009 6:35 pm   

Zbych pisze:

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

Wed Nov 11, 2009 6:45 pm   

SM przemówił ludzkim głosem:


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.

Wed Nov 11, 2009 6:47 pm   

....chodzi o czas Round-Trip Delay wynoszący 1,5us.

"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