PIC vs AVR

Dzięki, ten wygląda rozsądnie; nieskomplikowany, taki, w sam raz. 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

Jeśli tyle zarobię. ;-)

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:

i jedna z obowiązkowych lektur:

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

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.

Przypomniałem sobie jaki programator SWD obsługuje OpenOCD.

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

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.

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.

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.

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.

W dniu 07.04.2014 o 15:23 Piotrek snipped-for-privacy@pisz.na.berdyczow.info> pisze:

Bo to akurat nie było do ciebie tylko do pszemola :) a tutaj napisałem bo dałeś przykład fajnej płytki z fajnmym wszystkomającym prockiem z pdfem na >1800str.

Dziękuję za te "zaklęcia" wolę sam ustawiać peryferia, a to dlatego że 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.

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.

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.

Nie mylimy. Zastanawiamy się tylko jak to możliwe, ż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.

Po analizie głównej pętli sortującej widać, że: 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.

W dniu 2014-04-07 23:35, Sylwester Łazar pisze:

Z czego wynikają twoje projekcje na temat mojego ewentualnego zachowania? Jakiś uraz osobisty?

Twoje rozważania na temat efektów kompilacji na PICach zostały uzupełnione przez Janusza, który podał efekt kompilacji na AVR (1.6). Z tego wynika, że mogą być kompilatory dające wydajniejszy kod niż te dla PICów. Tak więc z tej waszej analizy można co najwyżej wyciągnąć wniosek, że programiści c powinni unikać platformy PIC, a programiści asm bardzo przywiązani do architektury nie powinni przechodzić na c bo mocno stracą na wydajności kodu. Nie wynika jednak z tego ogólna zasada, że kompilowanie z c ma dawać wielokrotnie mniej wydajny kod.

W dniu 2014-04-07 23:17, Sylwester Łazar pisze:

Bo on niczego innego nie potrafi. Co więcej! Ten mikrokontroler ze swoim programem nie potrafi uruchomić innego silnika, nie obsłuży innych sond niż te dedykowane, nie skomunikuje się z modułami firm "trzecich", nie wykona skryptu użytkownika. On robi tylko 25 rzeczy "jednocześnie" i nic ponadto nie umie. PC robi ze 300 razy więcej rzeczy "jednocześnie" i na dodatek jest gotowy na kolejne setki tysięcy innych zadań bardziej lub mniej przewidywalnych.

Widocznie używasz armaty na muchę. Zainstaluj DOSa na 386 33MHz. Wąskim gardłem w tych komputerach była dyskietka albo dysk twardy więc możesz dać kartę CF - bardzo fajnie działa. Jeszcze tylko trochę gimnastyki z obsługą sieci i już. 640kB starczy na system i uruchomienie czytnika e-mail. A jak Ci się znudzi to go zamkniesz i uruchomisz edytor tekstu. Chiwritera o ile pamiętam na 286 nawet używałem bez zacięć. Potem z niego wyjdziesz i dla rozrywki uruchomisz Pacmana czy innego węża. To Ci będzie szybko startowało i szybko działało. A do sortowania wiadomości poprawisz czytnik i napiszesz własną procedurę sortowania w ASM. Tylko czy tablica 65536 elementowa starczy? Zakładamy że starczy, ale potem to już nie będzie tak prosto przerobić przez dodanie 'long' przed 'int'.

I tu znowu się mylisz... Ten komputer przez pierwsze parę sekund pracuje w tzw. otwartej pętli, właśnie po to aby dac czas się silnikowi nagrzać, czujnikom ustalić swoje odczyty itp, itd... Wbrew pozorom komputer pokładowy w samochodzie nie ma wiele do roboty, zwłaszcza jeśli chodzi o obsługę samego silnika..

Ja nie widzę powodu dla którego nie mógłbyś w 15 sekund na tym komputerze odpalić MS-DOSa 3.30 i pocztę w trybie ASCII odczytać np. programem do poczty pod MS-DOS o nazwie Menuet czy jakoś tak.

Problem jest inny - Ty odpalasz silną maszynę uniwersalną mogącą Ci pomóc zaprojektować stację kosmiczną lub silnik odrzutowy w CAD i używasz jej do odczytania skrzynki pocztowej co może zrobić telefon.

Naprawdę ciężko z Tobą się rozmawia: Przecież masz tam specjalnie naznaczone, że porównuję do PIC18F Jak można wyciągnąć wniosek, że można porównywać kod C z jednego uC z kodem ASM z drugiego.

Poza tym masz JASNO i WPROST napisane, że chodzi o CYKLE, a nie instrukcje. czyli to jest porównanie czasowe jednego uC z zupełnie innym.

No nie wiem jak musi pracować umysł człowieka, aby wyciągnąć wniosek, że w takim razie kod w C dla TEGO SAMEGO uC jest tylko 1,6x wolniejszy.

Przecież w tamtej dyskusji porównywane były zupełnie inne uC.

Nie da sie z Tobą rozmawiać, bo wybrałeś sobie losowy współczynnik z dyskusji i usiłujesz wyciągnąć wniosek, że jak sobie napiszesz w C i skompilujesz to tylko 1,6x wolniej Ci to chodzi, niż napisałbyś na tym samym uC w ASM.

Toż to bzdura.

Równie dobrze mógłbyś spojrzeć na temperaturę za oknem i jak ci wyjdzie 1, to oznacza, że nie warto pisać w ASM, bo to to samo co w C.

Ale zaraz zaraz.... A wiesz, że możesz mieć rację?

Jakbyś Ty napisał niezbyt udany kod w asm i w C, to u Ciebie mogłoby być: Tc/Tasm = 1,6. Po co się ograniczać. Niech będzie i Tc/Tasm = 0,1

I teraz już wiem. Ty już zrobiłeś sobie takie doświadczenie. Napisałeś w C. Wyszło Ci, że Twój kod sortuje Ci 5 liczb w 5 sekund, a potem napisałeś swój kod w ASM i wyszło Ci, że liczy w 50 sekund. Teraz rozumiem, dlaczego piszesz w C. Wyciągnąłeś prawidlowy wniosek ;-) Śpij spokojnie. S.

To pisz dalej z telefonu :-)

Twój telefonowy czytnik newsów: "Microsoft Windows Live Mail 14.0.8117.416"

Dobranoc:-) S.