SM wrote:

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

do góry

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

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

do góry

SM wrote:
> 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

do góry

> A napiecie za LDO roslo powoli?

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

do góry

SM przemówił ludzkim głosem:

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

do góry

> A to że host wysyła pakiety do urządzenia co 1ms, to już ci nie
> 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

do góry

SM przemówił ludzkim głosem:
>> A to że host wysyła pakiety do urządzenia co 1ms, to już ci nie
>> 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.

do góry

Zbych pisze:
> SM przemówił ludzkim głosem:
>>> A to że host wysyła pakiety do urządzenia co 1ms, to już ci nie
>>> 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.
>

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

do góry

SM przemówił ludzkim głosem:

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

do góry

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

do góry