Czy Atmel nadaje się do WC ?

Porównuję oczywiście to co się da porównać. Architektura 51 i RISC to co innego.

No nie oznacza.

Ale przeciez Atmel jest identyczny - za pol roku wyjdzie errata w ktorej opisza to co odkryles :-)

To wlasnie PICe maja opinie majacych mniej bledow.

J.

Użytkownik "Tomasz Jabłoński" snipped-for-privacy@ep.com.pl> napisał w wiadomości news:d195pc$bqi$ snipped-for-privacy@nemesis.news.tpi.pl...

To było dawno (1992), to nie ja pisałem program (nie znam PICów). Wiem tylko tyle, że w erracie był schemacik (kilka bramek na zewnątrz), który należało zastosować, aby zsynchronizować przychodzące przerwania z zegarem PICa. Bo jak nie, to była jakaś króciutka chwila w takcie jakiegoś rozkazu (może modyfikacja kierunku), że jak akurat wtedy było zbocze to on nie zauważał. Nam się to objawiało tak, że mniej więcej co 1000 przerwań jedno przegapiał. A o tym schemaciku dowiedzieliśmy się z erraty po ponad roku. P.G.

problemu.

mechanizmem

Możliwe, że to jest to, tylko wtedy nie było to opisane w dokumentacji. O ile pamiętam, to jak już wiedzieliśmy (temat i tak był już dawno nieaktualny) to i tak wniosek był taki, że nie da się załatwić programowo. Albo ten ich układzik, albo przełączyć przerwania na port w którym są tylko wejścia. Jakbyśmy od razu połączyli inaczej, to w ogóle nie nacięlibyśmy się.

Ale to było na prawdę dawno i mogę być nieprecyzyjny, od wtedy PICe są poza obszarem naszego zainteresowania. P.G.

A sprawdzales na oscyloskopie? Pzdr Michal

Ta szlachetna prostota wychodzi mi bokiem:

1. Bankowanie RAM. W PIC18 z 4KB trzeba bujać się bez sensu z 16 bankami po 256 bajtów. Kompilator Hitecha każe spadać gdy tworzy się tablicę >256 z obiektami sizeof() > 1.
2. Rozszerzenie RAM (PIC18F8720) to parodia bo znajduje się on w przestrzeni adresowej ROM (!) i dostęp jest możliwy tylko przez jeden wspólny dla ROM/RAM rejestr TBLPTR. Czyli wydajność spada na ryj gdy konieczna jest obsługa XRAM (lub zewnętrznego I/O). Chyba ludzie z M. nie słyszeli o architekturach Load-Store które ładnie rozwiązują problem RAM.

Z tym to w ogole jest kanal i nie tylko w picach. Wszystko pieknie poki mamy wszystkich pamieci ponizej 64KB lacznie i miesci sie to w jedna przestrzen adresowa ze zunifikowanym dostepem. A jak chce sie wiecej .. to C pietrzy problemy. Czas sie na ARMy przesiasc jak malenstwa przestaja wystarczac :-)

J.

On Wed, 16 Mar 2005 21:01:01 +0100, point snipped-for-privacy@uymail.com.BEZSPAMU> wrote: [.....]

Wypisz wymaluj DPTR z 51. :-)

Pewnie nie słyszeli, bo po prostu odkupili 1802 od RCA i zrobili z tego PIC-a. :-) Nie chce mi się sprawdzać, ale architektura pod względem wieku porównywalna z MCS51, a być może nawet starsza. :-)

Regards, /J.D.

On Wed, 16 Mar 2005 21:08:46 +0100, J.F. <jfox snipped-for-privacy@poczta.onet.pl> wrote: [.....]

Maleństwa, tj. PIC12xxx bardzo mi się podobają i IMO jeszcze długo będą wykorzystywane. I wg. managementu Microchipa chyba też - nie tak dawno przecież wypuścili PIC10. Ale zamiast wypasionego PIC18-a za $9 może lepiej jest kupić ARM-a Philipsa za tą samą cenę i uniknąć wszelkich niedogodności związanych z programowaniem uC/uP ośmiobitowych.

BTW. AFAIR nowy LPC2138 (32KiB RAM, 512KiB Flash) kosztuje w Kamami (czyli w detalu) około 60zł brutto, starsze i "mniejsze" kości okło 40zł.

Regards, /J.D.

Jan Dubiec napisal(a):

Ja bardzo prosze o nieporownywanie PICa i 51, ponieaz uwlacza to

Marcin E. Hamerla napisał(a):

Nowe 16-bitowe procesory dsPIC mają zupełnie nową architekturę. Oraz nowy kompilator bazujący na gcc.

szlovak napisal(a):

Taaa

I co z tego? Latwiej zapamietac: MOV R0, #2 niz qjerjfwiwufujhshwi 2

Etam, nie każdy pic jest prosty jak młotek, są wersje bardzie rozbudowane/wydajne pomijając nawet dsPIC

wystarczy chcieć. Przecież to 51 ma więcej komend niż przeciętny PIC, nawet taki z serii pic18 ma mniej komend niż w 51

nie "qjerjfwiwufujhshwi 2" tylko

movlw 2 movwf coś

gdzie coś to dowolna komórka "file registers"

No w mądrzejszych PICach jest szybciej, jest więcej komend, ale w podstawowych jest tak.

Właśne fajne jest to że nie trzeba korzystac z innych komend żeby załadowac wynik do komórek pamięci jak w 51. Do tego działania wszystkich funkcji odbywają się na dowolnym rejestrze i akumulatorze (W) W 51 wszystkie operacje są na akumulatorze, B i rejestrach R0-R8 , dopiero wynik można sobie przenieść do jakiegoś ramu. W PICach od razu wynik może być w każdej komórce ogólnego przeznaczenia lub rejestrze W.

A tak w ogóle możesz pisać w C jeśli to przeszkadza, powinno być wtedy łatwiej

Pozdrawiam Adam

Marcin E. Hamerla napisał(a):

hehe, miałem dokładnie taki sam problem, jak musiałem raz użyć PICa. jeszcze lepsze jest tworzenie i odczytywanie tablic ze stałymi (;

w.

Eeeee, można bezpośrednio operować na wewnętrznym ramie inc 32 anl 32,#3 mov 32,#4 itp.

Racja , częściowa, ale np: ADD; ADDC; SUBB wynik pozostawi TYLKO w akumulatorze. W PICu można zostawić wynik w komórce bioracej udział w dodawaniu

odejmowaniu itp

IMHO fajniejszym rozwiazaniem jest atmelowy AT91SAM7S256 (256KB Flash ale za to 64KB RAM, USB slave), no i kosztuje okolo 40 zl. Juz mamy w firmie probki i niedlugo sie za niego zabierzemy. :)

Kosztuje? Tzn. mogę go sobie kupić? Czy może jest to, póki co, produkt wirtualny? :-)

Regards, /J.D.