PIC vs AVR

Przy rozważaniach czym jest programowanie, a szczególnie ile ma wspólnego z komputerami i nauką zawsze mam skojarzenia z wstępem do tego wykładu:

W dniu 2014-04-08 22:41, jacek pozniak pisze:

"Jak rozpętałem wojnę PICowo AVRową" :)

Ale tak na prawdę nie był to flame pics vs avr a raczej programowanie w asm vs. reszta świata.

Jak się już rozpęta to nikt nie patrzy kto z kim, jak i czym wojuje.

Widać od razu, że problem z tematu jest nietrywialny ;-) S.

Anienienie. Problem jest trywialny, tylko nikt nie stara się dostrzec źródła problemu, a co za tym idzie rozwiązania. :-)

Piotrek

Pieniądze?

Poniekąd. Ale raczej miałem na myśli model jaki się przyjmuje przy planowaniu biznesu.

Wiadomo, że inne kryteria przyjmuje się dla produkcji wielkoseryjnej, robionej na marży na przykład 1%.

A inne dla produktów krótkoseryjnych (albo unikatowych) dla których nikt rozsądny nie wpuszcza się w optymalizacje robione programistą bo jest to po prostu za drogie.

I tu jest IMHO główne kryterium, a nie jakieś dziwne wnioski, że algorytm implementowany w assemblerze ma koszt liniowy podczas gdy *ten sam* algorytm implementowany w C ma koszt wykładniczy i dlatego należy używać assemblera.

Bo to jest IMHO herezja wynikająca prawdopodobnie z "dodawania gruszek do śliwek".

Piotrek

Fajne. Dzięki. Mądrze gościu mówi.

p.s. interpreter LISPa na PICe ktoś ma? ;-)

biznesu ...nikt rozsądny ... bo jest to po prostu za drogie... dziwne wnioski, że ... ma koszt liniowy ...ma koszt wykładniczy

Ale zauważyłeś, że tylko Ty mówisz w kółko o kosztach, a ja nawet o tym nie wspomniałem?

To co piszesz jest oczywiste. Tak samo jak oczywiste są cechy: jakości i ceny plastikowych produktów w TESCO.

Dla obu przypadków istnieje możliwość kompromisu. Tzn. Jeśli dla pierwszego napisanie fragmentu 50 linijek kodu: _asm ... ... _endasm

zamiast #include mamtogdzies.h spędza sen z powiek, to pewnie już tak pozostanie. Mimo, że poświęci na to 8h pracy, czyli co 10 minut linijkę. S.

Bez C ludzie jakoś się obejdą, bez butów nie bardzo.

Wszystko fajnie, tez lubie takie analizy i cieszy mnie ze sie tym zajmujesz. Sam mialem duzy fun pisza optymalny kod w asm na EmotionEngine i tez preferowalbym rozwiazania minimalne ale "warto" bylo uzyte w sensie "czy za to ktos jest gotow zaplacic". Bo wg. mnie w obecnym swiecie liczy sie przede wszystkim niezawodnosc i szybki czas realizacji projektu a nie niskie zuzycie zasobow. Tego typu projekty mozna policzyc na palcach jednej reki drwala po wypadku z pila mechanicza i dotycza dosc specyficznej niszy jakimi sa urzadzenia bezprzewodowe przeznaczone do pracy liczonej latami.

Powiem wiecej zastawiam czy przy obecnej dostepnosc mocnych procesorow i pelnych systemow operacyjnch (w tym RT) wogole pisanie na goly hardware ma dzis jakikowwiek sens.

Pozdrawiam

Marek

Nie to ze sie nie da. Chodzi o to ze Ci ktorzy na sile chcieli wymyslec optymalne rozwiazanie na to nie wpadli - a kompilator wpadl.

Wierz mi ze wydzial byl i nadal jest w czolowce rankingowej. Promowanie assemblera jakie usilujesz robic to jest wlasnie zla robota, bo jak juz pisalem niezawodnosc i latwy maintanace jest najwazniesze a to wlasnie ulatwiaja jezyki wysokiego poziomu.

To ze obecnie soft jest opasly to wina gigantycznych bibliotek i a nie samego faktu uzywania jezykow wysokiego poziomu. (Mam na mysli C/C++ ktore aktualnie przez niektorych jest zaliczane do niskiego poziomu).

Twoja wiedza na temat mojej osoby powiedzmy delikatnie, jest mało precyzyjna. Zaczynalem od assemblera 6502, potem m68k (poezja) i x86. Jeden projekt na MotionEngine (MIPS+). Liznalem tez Sparc, Alpha oraz Powerpc i ARM jesli chodzi o architekture i asembler.

W przypadku uC zas to pisalem na x51 (asm i C), AVR (asm i C) oraz aktualnie ARM (C/C++). I powiem to tak: Nigdy wiecej 8-bitowych gowien.

Pisze tez na duze komputery i doceniam dobre biblioteki ktore nie tylko uzywam ale i kupuje. Mozna na nowo pisac to juz zostalo napisame i przetestowane tysiace razy - tylko po co ? Zdecydowanie lepiej jest stosowac sprawdzone rozwiazania niz probowac cos udawadniac swiatu.

A prawda jest taka ze meczenie sie w 8-bitowych wynalazkach ze 128B SRAM i 5-ciam rodzajami pamieci kiedy dostepna jest 32bitowa jedna liniowa przestrzen adresowa jest IMHO swego rodzaju masochizmem. Tak samo jak uzywanie asemblera do komercyjnych projektow gdzie trzeba czegos wiecej niz migania diodami.

No coz zycze powodzenia. Nie raz juz sie przekonalem ze wygrywa nie rozwiazanie technicznie najlepsze tylko optymalne rozwiazujace dany problem.

Pozdrawiam

Marek

:-) Akurat tu nie masz racji... bo nie chodzi tu o buty tylko od szewców. Butów od dawna się już w większości nie naprawia - to co kupiesz to jednorazówki które nosisz dopóki są ładne a potem kupujesz nowe... Wszystko co jest w sklepach, może 99% to buty produkowane maszynowo. Pomijam jakieś ekstremalne przykłady butów szytych ręcznie na miarę...

Zresztą i tak to nic nie zmienia w dyskusji - szewc to był tylko przykład, element retoryczny... chodzi tu o przykład rzemieślnika.

To są Twoje własne słowa. Podobają mi się. Krążysz w zamkniętej pętli :-) S.

Mi też. I mimo upływu lat dalej tak uważam.

Ciekawa to obserwacja, zwłaszcza że pochodzi od Ciebie... :-) Od długiego czasu nikt tu nie wie co Ty właściwie próbujesz udowodnić tutaj...

Np co mialo znaczyc sprawdzenie ze piszę na usenet (i email) nie tylko z telefonu ale również z peceta? Albo po jasną cholerę w ogóle wciągnąłeś do tej dyskusji pecety? Nie, nie musisz wyjaśniać... zróbmy 'break' z tej pętli :-))

Pozdrawiam. S.