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

> 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

do góry

SM wrote:

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

do góry

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

do góry

SM pisze:

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

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

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

do góry

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

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

do góry

> 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

do góry

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

do góry

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

do góry

On 10 Lis, 06:36, SM <b...@k...com.pl> wrote:
> 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?

do góry

shg pisze:
> On 10 Lis, 06:36, SM <b...@k...com.pl> wrote:
>> 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?

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

SM

do góry