PIC czy AVR? Doświadczenia z kompilatorami HiTech i GCC w programowaniu uC

Mon Apr 07, 2014 2:46 pm   

I to podkreślone.
Można porównywać:
a) liczbę instrukcji
b) czas wykonywania.

Tak sie złożyło, że ja podałem w temacie porównanie C do ASM dla PIC18F.
Ludzie skompilowali na inne procesory i gdzieś tam trzeba było,
dla ciekawego przypadku, przejść do tego wątku:
PIC vs. AVR.
I tam dokonałem porównania czasowego z ATMEGA32.

Więc analizę przeprowadziłem, wydaje mi się dość rzetelnie,
a dodatkowo zawarłem porównania do innych procesorów i jeszcze kilka uwag.
Wątek był wydaje mi się ciekawy i jest wiele fajnych wniosków
Ty nie zrobiłeś jakiejkolwiek analizy porównawczej,
więc Twoje zachowanie wygląda na ujadanie psa, któremu nie podoba się....
no właśnie co?
Wolisz mieć dyskusje o kablu do garażu?
--
-- .
pozdrawiam
Sylwester Łazar
http://www.alpro.pl Systemy elektroniczne.
http://www.rimu.pl -oprogramowanie do edycji schematów
i projektowania PCB.

Mon Apr 07, 2014 2:47 pm   

Kiedyś już zerkałem w stronę LPC, ale tak tylko kątem oka.
Pomału będę ogarniał oprogramowanie (kompilator) i programator.
Prąd nie jest superkrytyczny do celu w jakim chcę go zastosować.

Spróbuję przeportować soft.
Mam nadzieję że się powiedzie.


jp

Mon Apr 07, 2014 2:50 pm   

Mon Apr 07, 2014 4:35 pm   

W dniu 2014-04-07 11:25, jacek pozniak pisze:

Ten bliżej złącza mini USB to ST-Link, drugi jest podpięty do testowania
jego możliwości.


Tak. Tylko dwie zworki trzeba zdjąć - są opisane. Na szpilkach masz
wyprowadzone wszystkie niezbędne sygnały do programowania/debugowania
swoich urządzeń.


Jeszcze OpenOCD potrzebne.
A jak przygotować całkowicie darmowe środowisko które będzie
współpracować między innymi z tą płytką masz tu:
http://gnuarmeclipse.livius.net/blog/install/

i jedna z obowiązkowych lektur:
http://www.freddiechopin.info/pl/artykuly/35-arm/79-przykady-dla-stm32-stm32f10x-standard-peripherals-library


Nie używam Linuxa, ale ludzie bez przeszkód i pod nim pracują.


--
Michał

Mon Apr 07, 2014 6:37 pm   

W dniu 2014-04-07 13:16, Dariusz Dorochowicz pisze:

Miałem na myśli demo, którym sprawdzisz działanie płytki, czy wszystko
pracuje OK, a bo ST daje przykłady właśnie dla Keila i IAR. Takie
rozwiązanie Plug and Play dla zupełnie początkującego - zainstaluj
Keila, podłącz płytkę, kliknij debug i zobacz, że to działa; zmodyfikuj
i znów sprawdź. Ja na początku używałem Raisonance z GCC (już nie
pamiętam jakie miał ograniczenia, ale mi wystarczało) i ładowałem przez
RS232 do STM32F103. Na dzień dzisiejszy jest prościej i tanio. Jak
proponowałem - Eclipse z pluginem i nie trzeba się bawić z makefile jak
ktoś nie ma na to ochoty.

--
Michał

Mon Apr 07, 2014 6:38 pm   

On 2014-04-07 16:47, jacek pozniak wrote:

Przypomniałem sobie jaki programator SWD obsługuje OpenOCD.
http://www.versaloon.com/
Można sobie złożyć samemu albo kupić w necie za jakieś 80 zł.
Trzeba trochę popracować aby go dodać do OCD i poza tym zbudować
toolchaina do pisania i kompilowania (tutorial na stronie Freddiego
Chopina)..
Stosując LPCXpresso masz gotowe środowisko. Tylko że oni mają własne
niektóre biblioteki i jak się do nich przyzwyczaisz to później będzie ci
trudniej gdy przejdziesz na toolchain oparty na Eclipse + CDT i
sterowniki CMSIS. Ponadto LPCXpresso trochę rozleniwia bo nie wymaga
stosowania makefile (ale można wybrać jego stosowanie). Ja w każdym
razie wolę żeby wszystkie ustawienia kompilacji były w pliku makefile
żeby nie szukać w menu IDE.


Powodzenia.


--
pozdrawiam
MD

Mon Apr 07, 2014 6:39 pm   

W dniu 2014-04-07 13:22, Dariusz Dorochowicz pisze:

W firmie wszystkie płytki mają takie samo złącze, a tak naprawdę w
docelowym produkcie jest bootloader i ładowanie przez kartę SD. A jak
ktoś kiedyś będzie chciał koniecznie coś programować to piny są opisane.

--
Michał

Mon Apr 07, 2014 6:43 pm   

W dniu 2014-04-07 13:47, Dariusz Dorochowicz pisze:


ale +VAT


pytanie było o 8 nóżek, po co w takim dużo więcej?
BTW - jak się poszuka, to ARM-y (ale z trochę z większą ilością nóżek)
są też robione w wersji 5V (a nie 3,3V), np. Kinetis E czy Toshiby.

--
Pozdr.
Michał

Mon Apr 07, 2014 6:53 pm   

On 2014-04-07 16:46, Sylwester Łazar wrote:

Czas wykonywania to nie jest analiza czasowa?



Porównanie czasowe to nie jest analiza czasowa?


Człowieku opanuj się trochę. Wyzywasz mnie od kłamców. Piszesz, że
ujadam jak pies. Weź coś na uspokojenie albo rozpędź się i pierdolnij
baranka o ścianę.
Skoro przeprowadziłeś rzetelnie analizę , z której wynika że c/asm = 1.6
to chyba mogę napisać, że c/asm = 1.6.
Ty mi zarzucasz kłamstwo i piszesz, że 16.



--
pozdrawiam
MD

Mon Apr 07, 2014 7:41 pm   

Jest. Tylko ja jej NIE ROBIŁEM.
A<>B.
Oznacza to, że jak robiłem A, to nie robiłeł B.
Czy to tak trudno zrozumieć?
LICZBA INSTRUKCJI w asemblerze po wykonaniu kompilacji do LICZBY INSTRUKCJI
,
napisanej w czysym asemblerze przez biegłego programistę dla TEGO SAMEGO
MIKROKONTROLERA,
którym jest PIC18F2320.
Nazwane przeze mnie: C/ASM=ileś tam, nie oznacza, że czas wykonywania kodu
napisanego w C, do czasu kodu napisanego w ASM,
czyli:
Tc/Tasm może być 2,6,10, 100.
Ale 1,6 jest moim zdaniem mało prawdopodobne.

I ja takich porównań nie robiłem, poza jednym wyjątkiem co do ATMEGA32,
gdzie analizę Tc/Tasm przeprowadziłem na podstawie zajrzenia do dokumentacji
obu mikrokontrolerów i sprawdzenia:
a) maksymalnego CLK
b) liczby cykli/rozkaz.

Jeszcze raz:
Tc/Tasm <> C/ASM

Mogę to jeszcze jaśniej wytłumaczyć, ale jesli tego nie zrozumiesz no to już
nie wiem czy sens istnieje.
S.

Mon Apr 07, 2014 7:50 pm   

W dniu 07.04.2014 o 15:23 Piotrek <piotrek@pisz.na.berdyczow.info> pisze:


a tutaj napisałem bo dałeś przykład fajnej płytki z fajnmym
wszystkomającym prockiem z pdfem na >1800str.


takimi "zaklęciami" posługuje się np bascom czy avrduino, akurat kiedyś
dawno temu pisałem w bascomie i takie konie dawał że głowa mała,
"zaklęcia" maiały bugi, wychodziło że lepiej to samemu w asm-ie ustawić
tylko że bascom był dość odporny na wstawki, skończyło się tak że się
przeprosiłem z c i na nie przeszedłem, chociaż mi nie leżał ze wzgledu na
małą czytelność kodu w stosunku do np pascala.


--

Pozdr
Janusz

Mon Apr 07, 2014 9:05 pm   

W dniu 2014-04-07 14:12, AlexY pisze:

Mylicie system otwarty z wbudowanym i do tego czasu rzeczywistego.
Porównujecie systemy o skrajnie różnym stopniu złożoności.

--
Michał

Mon Apr 07, 2014 9:10 pm   

W dniu 2014-04-07 21:41, Sylwester Łazar pisze:

Skoro jak sam podałeś instrukcje są wykonywane w jednym takcie to czas
wykonywania będzie zależał od taktowania. Skoro piszesz że kod po
skompilowaniu może być 16 razy wolniejszy i trzeba dać 10 razy szybszy
procek to chyba masz na myśli że po kompilacje ma się 16 razy więcej
instrukcji do wykonania a nie, że jest tych instrukcji jest 1,6 razy
więcej ale przy okazji obniżasz dziesięciokrotnie taktowanie.


Przecież podałeś proporcje liczby instrukcji i czasy wykonywania instrukcji.
Jakbyś nie kombinował z tego przykładu z AVR nie wykażesz, że po
kompilacji kod jest wielokrotnie mniej wydajny. Ani w ilości instrukcji
ani w czasie wykonywania.

--
pozdrawiam
MD

Mon Apr 07, 2014 9:17 pm   

że mikrokontroler powiedzmy 10Mhz w samochodzie potrafi w ułamek sekundy
uruchomić silnik,
dozować skład mieszanki paliwowej, zmierzyć 5 temperatur, odczytać stan
sondy Lambda,
sterować silniczkami krokowymi itp., a przyjemność jazdy jest wspaniała..
Drugi typ z kolei ma 1 000 MHz, 4 rdzenie, jest 100x droższy, produkowany w
10x większym wolumenie,
a nie potrafi uruchomić w ciągu 15 sekund skrzynki pocztowej,
abym mógł przeczytać wiadomość w trybie ASCII i przyjemność z korzystania
jest marna
i ciągle maleje.
S.

Mon Apr 07, 2014 9:35 pm   

stosunek czasu wykonywania kodu w C do czasu wykonywania kodu w ASM
będzie ok. 3x większy.

W pierwszym poście zrobiłem błąd.
Podałem:
"2) Testów czasowych _nie robiłem_, ale główna pętla przepisywania rekordów
ma w asm: 20 instrukcji,
a w C po przekompilowaniu: 121 instrukcji.
Wygląda na to, że w C program działa jakieś 6x wolniej."
Przeprosiłem za to i skorygowałem.
Chodziło o 121 bajtów,
czyli instrukcji tam jest ok. 60.
Czyli już masz Tc/Tasm = ~3x
Tc/Tasm = 1,6 jest liczbą nierealną.

Z moich doświadczeń wynika, że:
czasowo ten stosunek wychodzi jeszcze gorzej.

Ale to, aby było solidnie, należałoby zmierzyć dodając timer.
i dlatego analiza czasowa NIE BYŁA PRZEPROWADZANA.

Zobacz sobie na metodę qsort().
Tam używa się rekurencji.
Czyli jeżeli kompilator, (użyję Twojego języka i mojego)
jest nieoptymalny/spartolił sprawę w głównej pętli,
to rekurencji podlega także wykładniczo czas realizacji całości.

I właśnie rekurencyjny qsort() masz zaimplementowany w bibliotece C30
Microchipa w standardzie.

Może znajdzie się ktoś, kto dokona ANALIZY czasowej, bo ja niestety nie mam
czasu,
a tylko ochotę
A potem powiesz, że zrobiłem to, aby się pochwalić.


S.