ok, ok, ok .... nie jestem jakąs tam żmiją i obchodze sie bez jadu zupełnieA debuggowanie kodu ARM7 (i nie tylko) z RAM traktowanej jako pamiec programu tez jest bez sensu? Wrzuc na luz i mniej jaduuuu. Napisales (dwukrotnie), cos co wyraznie nie jest prawda choc i tak wiadomo o co chodzi. Byl to raczej "skrot myslowy" niz jakas wielka herezja, ale poczatkujacym moglo namieszac w glowach. Dlatego bis i ja rzucilismy uwagi porzadkowe (sluszne zreszta), ktore w zadnym razie nie podwazaly Twojego profesjonalizmu i mysle, ze kazdy pozytywnie nastawiony czlowiek odpisalby tylko "ok, racja". Nie rozumiem po co sie licytowac, tym bardziej ze zaleznie od implementacji program moze byc pobierany z pamieci RAM i kropka.Chciałem zwrócic uwage na codzienna praktykę, czyli rozwiazenia stosowane prawie zawsze, a nie na teoretyczne (bezsensowne? ) możliwości.

Program nie jest dla mnie czymś zapisanym w nieulotnej pamięci, ale zbiorem kodów pobieranych i wykonywanych przez procesor. To w jakiej pamieci jest ten zbiór zapisany dla działania procesora nie ma zupełnie znaczenia - przyznaje pełen pokory (chodz na boku dodaję "a jednak się kręci"

[ Dodano: 19-04-2006, 10:58 ]
Tomek nie pisze bo póki co nie ma potrzebya niektore nawet mniej (typu 32 bajty)Ale jak trafisz na procesory do których będziesz musiał napisać bootloader (bo ISP procka potrafi jedynie zapisać 128 bajtów z UARTU do RAM i tam skoczyć). Mysle, ze Tomek powie, ze bootloaderow i tak sie nie pisze, bo wszystkie zostaly juz napisane
.
Tomek powie że to prawda bo takie programy kiedyś pisałMysle, ze Tomek powie, ze to bylo dawno i nieprawda. Moze bedzie mial racje, ale jednak...A jeszcze inny przykład: w systemach opartych na Z80 w trakcie wykonywania skoku do tablicy przerwań część "rozkazu" (adresu skoku) dla procesora jest pobierana nie z pamięci ale bezpośrednio z układu generującego przerwanie.
