🚀 go-pugleaf

W dniu sobota, 1 lutego 2020 13:04:30 UTC+1 użytkownik Piotr Gałka napisał:
> 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.

no taka jest realnosc firm, ale szczerze mowiac, ona nie jest dobra..

a czy ta firma lub takie firmy nie zarabiaja na tyle wystarczajao zeby moc poswiecic 20-30% czasu na rozwoj/research ? (zwlaszcza jesli to jest sensowny potrzebny research a nie siedzenie przy kompie i ogladanie netu)..?