Użytkownik "Sebastian Biały" <h...@p...onet.pl> napisał w wiadomości
news:gp3pmb$nus$1@achot.icm.edu.pl...

> > Jak radzisz sobie z błędami w prockach ? Tak samo ? Może to wyjaśnia,
> > dlaczego niektórzy trzymają się 51 :)
>
> Biorę procek z poprawionym hardware.

Jak jest. Teraz są procki nie do końca stestowane i nie można powiedzieć, że
są poprawione albo nie poprawione bo czasem nawet błędy nie są
poidentyfikowane.

> W '51 nie ma się co popsuć bo ma
> dośc prymitywne bebechy

Nie, nie dlatego. PIC-e mają prymitywne bebechy a zdarzały się wpadki, tak
się niechluje śpieszyli. 51 jest po prostu stary i dlatego jest poprawiony.
Do czego dążę: zwracam uwagę, że w niektórych zastosowaniach to może być
jakiś argument.

> i wszyscy klepia go z grubsza na jedno kopyto.

Wszyscy w asm ? Akurat w przypadku 51 - wątpię. Bo jeśli chodzi o C to po
prostu producenci kompilatorów klepią wszystko na jedno kopyto i po
najmniejszej linii oporu, choć mieli jakieś 10 lat na udoskonalenia.

> Koszt wymiany AVR->ARM wynosi u mnie czas przepisania prostych driverów
> sprzetowych bo nie umoczyłem d... używając niszowego i jedynego w swoim
> rodzaju kompilatora jak to jest w przypadku '51 oblepiając go
> workaroundami na bugi w kompilacji.

Zasadniczo nie mając uprzedzeń co do żadnej z rodzin mikrokontrolerów (co
nie znaczy, że pewnych serii nie omijam szerokim łukiem) mogę powiedzieć, że
owszem, nowe rodziny bardzo sobie chwalę, używam, ale jakbym miał
argumentować na ich korzyść, to zdecydowanie temat błędów w kompilatorach
czy ogólnie błędów trapiących programistę zostawiłbym w spokoju. Byłem
zmuszony używać workaroundów w każdej rodzinie i w każdym kompilatorze
którego używałem. Kląłem na to, ale ma to i swoje plusy - po pewnym czasie
masz w miarę ustalone metody postępowania z kompletem procek-kompilator. Z
drugiej strony jeśli jakiś kompilator jest cały czas poprawiany, w pewnym
momencie przy odrobinie nieuwagi można sobie z programu działającego zrobić
niedziałający zamiast odwrotnie :)

> Mam pewien kod kompilujący się do AVR, ARM i PC (Linux + Windows). Tylko
> tak mogę go testować. Jestem przekonany że dodanie <wsadź tu arch
> supportowany przez gcc> kosztowalo by mnie popołudnie roboty - musze
> napisac tylko drivery do timerów, spi i portów.

Cóż, jest to fajne, że przenosisz kod bez grzebania w nim, ale - jak sam
zauważasz - i tak musisz grzebać gdzieś obok i z tym popołudniem to różnie
może być :). Kompilatory ani język C sam w sobie nie rozwiązują w cudowny
sposób nawet drobnych hardware'owych różnic między prockami. Nie wszystko
przewidzisz.

e.