🚀 go-pugleaf

W dniu 2020-02-01 o 09:07, heby pisze:

> Przykład: firma robi sterowniki. Tak nie za trudne, jakieś wejścia, 
> jakieś sterowanie, ogólnie nic skomplikowanego. Wybrali PICa, pod koniec 
> lat 90. Nie był to zły wybór.

Jesteśmy malutką firmą.
Na początku lat 90-tych klient zamówił opracowanie urządzenia 
dostarczając nam narzędzia do PICa (programator produkcji Microchipa, 
rozmiaru prawie A4 z wymiennymi modułami do różnych obudów). Na potrzeby 
projektu mieliśmy 10 szt PICów. Pierwsze 5 spaliliśmy bo ten ich 
programator włączając VPP między stanem początkowym 5V a końcowym 21V 
przechodził po drodze przez 45V. Zwykłe blank-check zabijało scalak.
Po namierzeniu problemu i zmodyfikowaniu tego programatora natknęliśmy 
się następnie na 3 różne błędy w PICu. Dwa udało nam się obejść, ale 
trzeci nas rozłożył. Według naszych pomiarów procesor przegapiał mniej 
więcej jedno na 3000 zboczy które miały dawać przerwanie, a odbieranie 
tych przerwań to była kluczowa sprawa.
Wysyłaliśmy faxy do Microchipa - bez odpowiedzi. Jakiś rok później 
odbyło się pierwsze seminarium Microchipa w W-wie. Tam obiecali, że 
przyślą nam erratę. Półtora miesiąca później dostaliśmy faxem tę erratę 
- zawierała 6 błędów (w tym te 3 które sami odkryliśmy). Aby obejść ten, 
który nas rozłożył proponowali dołożenie zewnętrznego układu 
synchronizującego zbocza przerwań z zegarem procka.
Gdybyśmy to wiedzieli przed projektem płytki....

Nasza decyzja - nigdy więcej PICów.

> Rzeczywistośc wygląda tak że od kilkudziesięciu lat siedzą dalej na 
> PICach.

Siedzimy od wielu lat na Xmegach.

> W rzeczywistości mają  
> kolosalny dług technologiczny bo rozwijali soft w asemblerze....

> Pytam o powody tego asm do dzisiaj

Bootloader mamy w assemblerze.
Nigdy nie programowałem mikrokontrolerów i żaden z nas nie jest 
wykształconym programistą. Z tego co brat mi mówi to on nie widzi 
możliwości napisania efektywnego SHA256 na Xmega w C. O ile pamiętam 
(rozmowa była z 5 lat temu) to problem polega na tym, że C zabiera z 
definicji kilka rejestrów i brakuje dla przechowywania stanu SHA256. A 
ciągłe przerzucanie danych między rejestrami a RAMem kilkukrotnie 
spowalnia obliczenia.

> i dlaczego PICe.

Z mojego punktu widzenia (projektuję schematy/płytki) Xmegi są na prawdę 
fajne. 7 UARTów, 3 SPI, 2 I2C, 16 wejść analogowych, przerwania z każdej 
nogi pozwala mi zawsze tak podłączyć peryferia abym nie musiał korzystać 
z drugiej strony płytki dla ścieżek sygnałowych.

> Potwarzam, intelekt praktycznie nic nie ma wspólnego z mądrością 
> wyborów. Decydują czynniki pochodzące czysto z biologii. Mechanizmy, czy 
> to duże korpo czy mała firemka, podobne.

Sugerujesz jakoby decyzje były głównie na zasadzie 'przyzwyczajenie'.
Ja to widzę inaczej.
Prawie przy każdym kolejnym projekcie zastanawiamy się, czy stać nas 
przy tej okazji na skok technologiczny, co spowoduje opóźnienie go 
szacunkowo o pół roku. Nasze doświadczenie nam mówi, że jak się nam 
wydaje, że coś nam zajmie t to zazwyczaj zajmuje 3t.
No i dotychczas zawsze było, że oprócz tego mamy do zrobienia 'na 
wczoraj' jeszcze kilka rzeczy i na pewno teraz nie możemy opóźniać.
Takich zaplanowanych, różnych skoków technologicznych do wykonania mamy 
jeszcze kilka. Do niektórych powstał nawet hardware i czeka od 4 lat aż 
znajdziemy na to czas.
P.G.