kayron pisze:Ja ogólnie przesiadłem się na 8-bitowe PICi, mam tam czyściutki kompilator zgodny w 98% z ANSI C, czyli kod jest taki sam jak na PC.
Ciekawe ile za niego zabuliłeś, bo Microchip nie jest skory do rozdawania za darmo pełnych wersji nawet prostych kompilatorów. Całkiem za darmo to se możesz w asemblerze popisać.
Programator PICKIT3, jak pamiętam 175zł, i masz to programator do PICów 8, 16 i 32 Bitowych,
+ prosty analizator stanów logicznych/"oscyloskop"
+ masz możliwość wgrania kodu do pamięci EEPROM programatora i zaprogramowania docelowego układu bezpośrednio z programatora bez użycia komputera. Wszystko wielkości NOKII X2, i mieści sie w kieszeni koszuli.
Który programator AVR, za te pieniądze ci to zaoferuje ?
Kompilatry C dla PIC16/18 HITECH są dostępne darmo w wersji LITE i jedynym ograniczeniem jest brak możliwości włączenia optymalizacji kodu, wyższej niż podstawowa, bo tam są trzy poziomy jak się nie mylę. Czy wada czy zaleta ? Hm.. kwestia potrzeb i upodobań. Dla mnie optymalizacja jest umiejętnością programisty, nie funkcją kompilatora, więć dla mnie nie jest to wada absolutna. Zresztą na BASCOMie też sie targało z ograniczeniami, i dało rady.
Nie wiem jak kompilatory na 16 i 32B PICi, bo nie szukałem, ale na 16B chyba też jest w wersji LITE.
32B PICi to architektura RISC MIPS tech, wiec nie wiem jak tam z kompilatorem?
Co do Asemblera PICów 8-bitowych, tam masz tylko 35 instrukcji (39 w PIC18), wiec do opanowania, nawet do wyrycia jak tabliczka mnożenia. A jak ktoś kiedyś programował w ASM C64, to jestem w stanie zaryzykować stwierdzenie że opanuje PICa w tydzień, bo CPU PICa przypomina do złudzenia, rdzeń 6502 z C64. Różnica taka że pamięć stronicowana, co jest trochę upierdliwe. No i stos jest sprzętowy, wiec ma ograniczoną pojemność.
A i PIC ma jeszcze jedną zaletę. Nie da sie go tak łatwo zablokować, jak AVR w FUSE BITach, przynajmniej jest to ciężkie zadnie. A nawet jeżeli tak sie stanie, to ten sam programator przełącza się na HIGH VOL, mode (zresztą i tak domyślny tryb) i można go odblokować. Nawet odłączenie końcówki RESET (zrobięnie z niej portu I/O), nie jest problem, jak to jest w AVR.
No nie wiem, na początku bałem się trochę PICów, ale jak je poznałem bliżej, to jakoś AVRy straciły dla mnie magię i czar. Teraz Microchip w nowych PICach wprowadził coś na wzór prostego PLD, czyli można usprzętawiać pewne funkcje, dotąd programowe, jak dekoder menchester. Jeżeli będą to dalej rozwijać i wyląduje tam takie prawdziwe PLD, czy CPLD, to AVRy całkiem dla mnie już stracą byt. Ogólnie Microchip dąży do stworzenia SOCa łączoncego, zalety klasycznego MPU i CPLD, a robią to fajnie bo takimi małymi kroczkami, i to mi się podoba, bo można to opanowywać sobie po trochu.
Na dzień dzisiejszy wygląda to tak:
http://ww1.microchip.com/downloads/en/D ... 41631B.pdf
Filmik
kayron pisze:to kompilator i tak mi to przetłumaczy jak bym to zapisał od razu tak:
Skąd wiesz, że GCC pod AVR tego tak nie złączy? Złączy i pewnie przekonasz się o tym w najmniej oczekiwanym momencie jak będzie trzeba coś wykonać stricte sekwencyjnie...
Owszem że tak zrobi, tylko, dla mnie czytelność jest mniejsza, Puki tam są same ORy "|" spoko, ale jak se wstawisz tam AND, lub XOR, to sie pewnie pogubisz w tym zapisie.
A skoro kolega wyżej twierdzi, że kolejność zapisu nie ma znaczenia, tym bardziej można się w tym pogubić.
Ja tu piszę nie o pisaniu własnego kody, tylko czytaniu czyjegoś kodu. Jeżeli osoba trzecia jest konsekwentna w zapisie działań, OK spoko, ale jeżeli raz ci to zapisze tak, a drugi inaczej, to sie zaczynasz w tym szybko gubić.
Jak już to JTAG ICE 3.
Xmegi bez JTAGA to dinozaury i są na wymarciu, o ile już nie wyginęły, więc nie ma problemu. Dragon z Xmegami chodzi bardzo sprawnie. O innych programatorach nie pisałem, bo są niewspółmiernie drogie w stosunku do ceny.
