PIC vs AVR

Nie ma problemu... Poczta, usenet - i z komputera i z tableta i z telefonu.

Czy Ty jeszcze pamiętasz o co właściwie Ci chodzi w tej dyskusji? Bo coraz bardziej się miotasz i na oślep strzelasz...

W dniu 2014-04-07 20:43, Michał Baszyński pisze:

No więc właśnie czasem 8 nóżek jest wystarczające, a zasobów jest mało. wystarczy że masz dwa urządzenia łączące się jakimś protokołem szeregowym, ale różnym, i nie masz możliwości ingerencji w nie. Tu często brakuje właśnie RAMu, bo sama obsługa protokołów jest względnie prosta i mieści się w całkiem niewielkim flaszu. Jeszcze więcej trzeba kiedy masz protokoły operujące na tym samym medium fizycznym i chcesz mieć urządzenie rozpoznające z czym ma do czynienia (bo czemu nie?) i żeby cokolwiek zacząć musisz zebrać trochę próbek tego, co przychodzi. Oczywiście zawsze można dać jakąś kostkę na SPI, ale w końcu nie o to chodzi.

Pamiętam, że były jakieś ARMy akceptujące 5V na IO, ale zasilane były z 3V.

Pozdrawiam

DD

W dniu 2014-04-08 00:58, Sylwester Łazar pisze:

To po co te twoje porównania z wyliczeniem 1.6?

No dobra w instrukcjach będzie 34/20 (w pętli głównej). Czyli 1.7

Założyłem, że kod asm na AVR będzie równie dobrze napisany jak ten twój na PIC :)

To ty się miotasz. Natchniony rozważaniami w innym wątku (na temat tego czy warto przejść na bardziej rozbudowane uC i na programowanie w C) wyruszyłeś na jakąś krucjatę i ogłosiłeś, że c jest 6 razy gorszy od asm. Wrzucasz jeszcze teksty, że razy 16 i że przechodząc na c trzeba przejść na co najmniej 10 razy szybszy procek żeby skompensować stratę wydajności generowaną przez kompilator. A przy dokładniejszch analizach wychodzi, że twój kod asemblerowy na PICu pędzonym 40MHz ma prawdopodobnie taką samą wydajność jak skompilowany z c kod na ATmegę

32 taktowaną 16MHz. Procek wzbudził twoje uznanie, a jest to procek który praktycznie znika już z rynku. Wygląda na to, że zahibernowałeś się w tym PIC i asm i nie widzisz co się wokół dzieje.

Wyzwałeś mnie od kłamców, stwierdziłeś, że ujadam jak pies, teraz twierdzisz, że jestem beznadziejnym programistą. Poprawia ci to samopoczucie i twoim zdaniem daje ci przewagę w dyskusji? Ciekawe czemu? Przecież jesteś przekonany o swoich umiejętnościach, których ja nigdzie nie kwestionowałem. Więc chyba nie jest budowanie nadwątlonego poczucia własnej wartości przez poniżanie innych. Może po prostu nie powinieneś pisać na newsy bo nie panujesz nad emocjami.

Sprawdziłem "pierwszy z brzegu", czyli ten Cortex M4 co ja używam w projekcie:

"6.2 Pin description I/O pins on the LPC408x/7x are 5V tolerant and have input hysteresis unless otherwise indicated in the table below. Crystal pins, power pins, and reference voltage pins are not

5V tolerant. In addition, when pins are selected to be ADC inputs, they are no longer 5V tolerant and the input voltage must be limited to the voltage at the ADC positive reference pin (VREFP)."

W dniu 2014-04-08 08:59, Dariusz Dorochowicz pisze:

takich jest dużo, STM32 (nie na wszystkich nogach), te z Texasa chyba też

To wina procesora, ze używasz (pewnie za karę) kiepski so z jeszcze bardziej kiepskimi aplikacjami?

Zgrubsza ? Dlaczego nie. Nowoczene procesory, nawet male, sa superscalarne i wykonuja instrukcje w pojedyncze cykle (to nie x51 gdzie byle g* zajmowala 50 cykli).

Upraszczajac przy dostatecznie duzej ilosci kodu mozna przyja, ze ilosc instrukcji i taktowanie CPU determinuje czas wykonania programu. ARM musialby miec srednio 10 cykli (a PIC 1) na instrukcje aby Twoje przesuniecie przecinka mialo sens. A tak nie jest- zobacz sobie ARM cycles per instruction.

wyzej masz wyjasnienie.

Roznie bywa. Na zajeciach na PW juz nascie lat temu najszybszy okazal sie program napisany w C(!). Powiedzmy ze na sparca sie trudno recznie optymalizuje co nie nie zmienia sytuacji, iz w grupie 20 osob z ktorych czesc implementowala algorytm w asm a czesc w C wygral ten napisany w C. Fakt ze pisany byl "assemblerowo" z bardzo duzym uzycie niskopomziowych operatorow ale nikt z reszty w asmemblerze nie napisal lepiej. Naprawde pewne optymalizacje kompilatora wzbudzaly muj szacunek do niego. Takze na malych uC mozna dlubac recznie i bedzie lepiej, na duzych procesorach, sorry nie widze tego. Zbyt duzo mechanizow. Czlowiek tego nie ogarnie. Sam fakt posiadania 32 128bitowych rejestrow powoduje iz sie mozna pogubic. A cache i przewidywaniu skokow nie bede nawet wspominal.

A warto ? Pytam powaznie bo mimo ze lubie assembler to nijak mi nie wychodzi ze warto.

Pozdrawiam

Marek

A czego oczekujesz od kogos kto ma wszytko napisane w asm na PICa ? :-) To wlasnie najwieksza "zaleta" asmeblera ktora go IMHO calkowicie dyskwalifikuje w komercyjnym uzyciu - nie zmienisz rodziny mikrokontrolero chyba ze napiszesz sobie wszystko od nowa.

Pozdrawiam

Marek

ja pie..ole, to nie miało być takie długie :-)

jp

jacek pozniak wrote:

Szanowny Kolego! Twoja wiedza na temat mojej osoby powiedzmy delikatnie, jest mało precyzyjna. Ja pisałem w C 20 lat temu, jak Twoi koledzy na PW nie umieli sklecić prostego kodu w ASM na laborce, który działa szybciej niż kod w C. Jest to o tyle zastanawiające, że źródła C można było podglądnąć po przekompilowaniu. Jeśli, jak piszesz, to była grupa osób i wszystkie stwierdziły, że nie da się zrobić tego co zrobił kompilator, to coś w tej historii się nie klei. Nie wiem jak to wygląda w tej chwili z rankingiem uczelni wyższych technicznych, ale jeśli jest tak jak piszesz, to znaczy, że przynajmniej ta grupa robiła złą robotę.

Oprócz tego napisałem trochę kodu na uC innych firm niż Microchip. Poza tym, nie wiem, czy wiesz, ale Microchip ma uC 16-bitowe oraz 32-bitowe.

32MX są z rdzeniem MIPS. O ile 12F, 16F, 18F stanowią pewną wspólna grupę, to z pewnością nie można tego powiedzieć o dsPIC30/33, którego budowa jest zupełnie inna. Z MX32 jest jeszcze inaczej, gdyż montują rdzeń kupiony od firmy na literkę N, H, S lub innej. Więc jak widzę, kiedy ludzie mówią: "ten to co pisze na te PICi", to wzrusza mnie prostota myślenia. Pamiętam, jak kiedyś pewna osoba zapytała: "A te PICi mają już przerwania?" Znam takie sformułowania i mnie nie bawią, bo świadczą tylko o pokazaniu, kto chce być górą. W szczególności śmieszne się wydaje, kiedy ktoś ma doświadczenia w A, B i C, F, H, I, P, M, Z, a drugi liznął tylko a i C i śmieje się z doświadczeń z literki A. Przy czym jego C polega na korzystaniu z H. Konkretnie ".h" i to cudzych :-) W nauce liczy się prawda, a nie rodzaj procka. Żaden uC nie nadrobi umiejętności kodera-programisty, mimo, że da się wybrać taki, który wykona kiepski kod x razy szybciej. S.

Zależy czym się zajmujesz. Ja lubię w ASM, dlatego, że podziwiam pracę inżynierów, któzy projektują takie skomplikowane rdzenie. Traktuje to jako swego rodzaju wyzwanie. Jeżeli trzeba dodatkowo zrobić coś szybko, to cieszę się, że mogę wykorzystać swoje umiejętności. Lubię też w C, ale to głównie dlatego, że fajnie się pisze i wygodnie. Ale realizacji wyzwań tam nie widzę. Chyba w walce, aby zmieścić się w zasobach i prędkościach.

Np. teraz. Zastanawiam się, w jakich przypadkach kompilator C używa takiego rozkazu z dsPIC30: np. MAC W4*W5, A, W4, [W8]+=2, W5, [W10]+=2, [W13]+=2

1) pomnożyć 2 rejestry 16-bitowe 2) dodać je do 40-bitowego akumulatora 3) pobrać komórkę (16-bitów ma się rozumieć) z pamięci do rejestru 4) i jeszcze jedną - tak samo 5) zaokrąglić do 16-bitów i zapisać drugi akumulator B do rejestru lub pamięci 6) zwiększyć wskaźnik na pobieraną z pamięci daną 7) i drugiego wskaźnika także. 8) zwiększyć też i ten wskaźnik zapisywania B do pamięci

To wszystko w 1 instrukcji. dla 30F4011@ fcy=30MHz trwa 33 ns. S.

W jakiej nauce?

I wykonanie kiepskiego kodu x razy szybciej to jest właśnie sposób na nadrobienie braku umiejętności kodera-programisty. Niestety.

Ale - najważniejsze "w nauce" są założenia projektowe... Jeśli projekt masz ukończyć w zadanym czasie za zadaną kwotę kosztów przy zadanej efektywności/wydajności końcowego programu to czasem trzeba użyć C/C++ a czasem trzeba użyć assemblera i warto znac oba aby nie mieć ograniczonego wyboru. Nie jest prawdą że ZAWSZE opłaca się dopieszczać kod z dokładnością do każdej instrukcji assemblera. Tym bardziej jeśli konsekwencją jest np. wyjście poza budżet pieniężny lub czasowy całego projektu. A więc można tą długą dyskusję podsumować twierdzeniem że nie należy podchodzić do tego zbyt fanatycznie i stosować takie narzędzia aby osiągnąć zamierzony cel w zamierzonym czasie.

Tym razem zgadzam się w 100%. Co do pytania o naukę. Mi się wydaję, że wiedza typu Know-how, jest jak najbardziej nauką. Nie wyobrażam sobie programisty-kodera, któremu zada się pracę: Napisz kod od 20 do 300 linijki kody, a ten robi po kolei:20, 21, 23 itp. To nie kopanie rowu, choć lubię czasem jakiś rów wykopać :-) Nie trzeba myśleć zbyt wiele. S.

No to fajnie.

A mi się wydaje, że pisanie kodu (tworzenie programów) to rodzaj rzemiosła. Dobry programista to tak jak dobry szewc lub spawacz. Do naukowca to mu jednak trochę brakuje, choć przyznaję że nauka i inżynieria często sobie nawzajem pomaga i idzie w parze...

Tym razem zgadzam się w 50%. Just swap it! Łatwo to sprawdzisz, jak każesz szewcowi czy spawaczowi napisać prosty kod w C. W drugą stronę: Ja nie mam problemu z prostym szyciem buta czy pospawaniem palnikiem acetylenowo-tlenowym prostej konstrukcji. S.

Napisać prosty kod w C lub pospawać prostą konstrukcję potrafi amator.

Dobry rzemieślnik, naprawdę dobry specjalista, tym różni się od amatora że potrafi DOBRZE i niezawodnie zrobić nawet najtrudniejsze zadania, projekty w swym fachu...

Jestem pewny, że nie każdy dobry programista-fachowiec będzie umiał pospawać nawet prostą konstrukcję stalową, bo do tego trzeba znać choć podstawy, czyli być hobbystą-spawaczem, spawaczem amatorem.

Jestem też pewny, że znajdziesz takiego dobrego spawacza-fachowca, który będzie umiał napisać prosty kod w C, bo jest akurat hobbystą, programistą-amatorem.

Wyczuwam w Twoim tonie sugestię o jakiejś wyższości programistów nad spawaczami czy szewcami, jakbyś nie doceniał kunsztu z jakim pracę wykonuje DOBRY rzemieślnik. Ja się z tym tonem nie zgadzam nawet w 1%.

Cenię każdego dobrego spawacza (wiem, jak trudno jest pospawać, bo robiłem). Cenię każdego dobrego szewca (wiem, bo mój dziadek był szewcem, budowlańcem, nauczycielem, cukiernikiem, pracował w hucie szkła i był super dziadkiem). Jednak, wiesz chyba co to jest drabina społeczna i dlaczego istnieje? S.

Ale ja nie o drabinie społecznej mówię...

Ja postawiłem tezę, że programista jest rzemieślnikiem a nie naukowcem. I próbuję tą tezę Ci objaśnić na przykładzie innych rzemieślników. Naukowcem być to jednak coś dużo więcej niż tylko wytworzyć kolejną parę butów albo kolejny program do sortowania tablicy danych...

Abstrahując już od tego ile czasu trzeba i ile nauki trzeba aby stać się dobrym szewcem czy dobrym spawaczem czy dobrym programistą i gdzie na drabinie społecznej się te zawody znajdują żaden z nich nie jest naukowcem jeśli tylko implementuje znane już i stosowane rozwiązania (w swojej branży). Wybacz jeśli Cię rozczaruję, ale nie ma tu nic naukowego w tym że ktoś napisze sortowanie bąbelkowe w C++ czy nawet w ASM - to tylko implementacja znanej i szeroko-stosowanej technologii i w istocie swojej niczym nie różni się w zaimplementowaniu metody spawania w osłonie argonu. Tu rzemiosło i tam rzemiosło. Różnica między C++ a ASM może być porównana do różnicy w szyciu butów ręcznie czy na maszynie do szycie... Albo spawaniu iskrowym czy w płomieniu...

Co innego gdy spawacz-naukowiec zacznie eksperymentować i w toku swoich poszukiwań opracuje nowe metody, nowe technologie, nowe materiały do spawania, wtedy otrze się o naukę tak samo jak taki koder rzemieślnik, który zacznie wymyślać nowe, nieznane wcześniej algorytmy sortowania danych czy też nowe nieznane wcześniej algorytmy szyfrowania. Czujesz teraz lepiej moją tezę?

Teraz tak. Ale weżmy takiego pana, co się nazywał Henry Ford. On to bowiem napisał, że: "In short, the result is this: by the aid of SCIENTIFIC STUDY one man is now able to do somewhat more than four did only a comparatively few years ago. That line established the efficiency of the method and we now use it everywhere. The assembling of the motor, formerly done by one man, is now divided into eighty-four operations--those men do the work that three times their number formerly did." Co się tłumaczy, że dzięki badaniom naukowym pewne algorytmy wykonywane są szybciej. Jednak wszystkie czynności, które były wykonywane wcześniej przez tych czterech, były znane. Problem był tylko jak te same czynności wykonać miał jeden.

S.