Adam Dybkowski pisze:

> To był AFAIR PIC16F877. Program się rozwijał przez długi czas od
> mniejszego procka, a ja dołączyłem do tego nieszczęsnego projektu tuż po
> przejściu na '877. Kupa kodu w asemblerze, rzeczywiście dopieszczonego
> ale mocno upstrzonego makrami bo inaczej w ogóle nie dałoby się nad tym
> zapanować.
>
> W dzisiejszych czasach - gdybym to miał pisać od zera - od razu wziąłbym
> jakiegoś AVRa albo małego Cortexa i pisał w C. Żadnego asemblera przy
> tej ilości kodu. A PICe nie są w końcu aż tak małoprądożerne jak to
> wynika z legend.

Ale to nie wina procesora, tylko typowe problemy z wchodzeniem w cudzy
program, na dodatek w asemblerze.
Trzeba było poświęcić kilka dni i przetransferować program na jakiś
układ z rodziny 18, który nawet ma taka sama pinologię. Robiłem to
dwukrotnie i jest to szybkie, oczywiście tylko w tę stronę. Jedyne co
trzeba zrobić to poprawić kontrolę peryferiów i pozamieniać globalnie w
mnemoniki w kodzie. Przynajmniej problemy ze stronicowaniem pamięci by
znikły. A potem na spokojnie można napisać tę sama aplikacje w C, jeśli
ktoś musi, i zapomnieć o mnemonikach Microchipa

Pice są wykonywane w różnych technologiach. Te w technologi nanowatt
pozwalają osiągnąć bardzo małe pobory prądu, jeśli sie mądrze zarządza
zasobami i używa stanów uśpienia. Bo jeśli się włączy rdzeń i wszystkie
peryferia na cały czas, nawet te które nie są non stop potrzebne, to
przecież cudów nie ma...

Pice zawsze miały też znacznie trwalszy i lepiej działający flash i
eeprom niż AVR-y. To Micorchop pierwszy wprowadził procesory z jedynie 8
nogami (chyba ze 20 lat temu) a potem pchełki wielkości tranzystora w
obudowie STT23-6. I to jest właśnie poprawne podejście do tematu uC. Do
każdej aplikacji odpowiedni element.

NIe wiem jak ostatnio , ale jeszcze zupełnie nie dawno do AVR-ów był
tylko programator, podczas gdy pierwszy debugger ICD i kompatybilne z
nim PIC-e pojawiły sie też ponad 10 lat temu. A to zupełnie inna jakość
w uruchamianiu urządzeń pracujących w systemach czasu rzeczywistego, a
takie jest właśnie główne przeznaczenie komputerów w jednej kostce.

Nie twierdzę, że PIC jest super i nie ma alternatywy. Ale firma oferuje
taką potężną gamę procesorów, stale ja rozwijając, że najnormalniej w
świecie nie widzę sensu wchodzenia w innego producenta. Po co, skoro na
wyciągnięcie ręki mam i pchełkę wielkości łebka zapałki, i dsPICa z
poteżnymi w stosunku do zwykłych uC możliwościami matematycznymi i DSP,
i 32 bitowe potworki. Każdy w kilku obudowach do wyboru. I wszystkie
podłączę do tego samego ICD2 albo ICD3 i napiszę program w asemblerze
lub C pod dopracowanym niezawodnym firmowym środowiskiem.

--

Pozdrawiam,

A. Grodecki