Wirnick napisał(a):
A to mnie zaciekawiło! Ja to robię sporadycznie i tylko wtedy gdy mam tylko pliki *.HEX, *.EEP. Jeśli mam projekt to wgrywam program prosto z Eclipse. W Eclipse już jest wstępnie sprawdzony i ewentualnie czyszczony(clean) projekt. Unikam zbędnych bibliotek, zbędnych danych, zbędnych funkcji - są jako komentarz w kodzie i czekają na ich użycie.
Ja to zauważyłem, podczas rozwoju jakiegoś kodu. Robiłem niewielkie zmiany, wgrywałem, testowałem i tak w kółko. Przy wyłączonej fladze automatycznego kasowania nie dało się pracować. Kod jest w 100% autorski. Zresztą raczej to nie ma znaczenia.
------------------------ [ Dodano po: 12 minutach ]micky napisał(a):
Zanim zaczniesz wyciągać pochopne wnioski (typu błąd w kompilatorze, w rdzeniu procka itp. ) to wstaw
porządnie zdjęcia jak masz to wszystko połączone, załącz kody źródłowe, pokaż fusebity, wklej co Tobie
programator w konsoli wypluwa (może wydaje Ci się, że dobrze poszło programowanie a tak naprawdę wyłożyło
się na jakimś obszarze pamięci i program wgrywa się częściowo). Od tego zaczyna się konkretne przedstawianie problemu.
W zdecydowanej większości przypadków okazuje się bowiem, że problem wcale nie leży w kompilatorze lub rdzeniu
Wow
Nie zamierzałem aż tak się angażować, by jedynie ciekawość zaspokoić. Jeśli efekt nie jest znany nikomu - to trudno. Nie ma po co aż tak mocno dociekać.
Nawet nie zachowałem wersji oprogramowania z błędem, w której to siało zapisami po całej przestrzeni adresowej, by móc eksperymentować. Zdjęcie procka... hmmm... płytka stykowa i przewody do programatora + kwarc. Nie ma czemu fot robić. A oprogramowanie - jakiekolwiek. Może być zwykła pętla while(1) a w niej wachlowanie pinem. Nie miało kompletnie żadnego znaczenia, co wgrywam. Wszystko się "uwieszało". Po poprawieniu błędu procek działa normalnie, również na każdym innym sofcie.