PIC vs ATMEL #2

[VF]

Thus spake hg12345 <hg12345 at freemail.hu>:

> adodik, hogy az ATMEGA ,ha nem a regiszterei kozott csinal muveletet 
> akkor bizony nem egy orajel egy utasitas. A periferiakban valamiben az 

Miert, a PIC 1 orajel alatt a memoriaval is tud muveletet vegezni?
Hogyan? Az W-be is at kell tenni, ha akarsz csinalni vele valamit.

> egyik tobb a masikban a masik. Kinek mire van szuksege. Az vectoros it 
> kezelesnek is megvannak hatranyai, bizony a elve minde vektorhoz kell 
> es IT header rutin, ez sok vectornal sok helyet foglal.

Valami ~130 byte. De ha nem tetszik, lehet hasznalni a PIC modszert is,
beirhatod minden vektorba ugyanazt a cimet, es akkor visszavezettuk
a problemat egy mar megoldott feladatra.
(Tehat az nem igaz, hogy a nem vektoros IT-nek barmi elonye lenne a
vektorossal szemben, mert a vektoros magaban foglalja a nem vektoros
lehetoseget)

> A PIC es megoldasnak is van elonye a kicsit lassabb feldolgozasa 
> mellett, a megfelelo program szelektalassal bizonyos pioritasokat 
> adhatunk az IT kezelesnek. (A 18 mar ketszintu kezelesu)

Atmelen is. C-bol nem tudom hogy, IAR doksiban az all hogy nem lehet
engedelyezni egymasba agyazott mexakitasokat, assemblyben nem gond...
Ezzel kapcsolatban viszont erdemes megnezni hogy a nagy RISC procikon
milyen tamogatas van ehhez, mit szokas mexakitasban csinalni, hogyan
kell egy a procit jol kihasznalo kernelt irni...
Kicsit mashogy szoktak csinalni, a mexakitasban csak egy nagyon rovid
kis progi fut le, signaloz egy megfelelo prioritasu taszkot.
Igy lenyegtelen a mexakitasok prioritasa, es nem is erdemes arra a
nehany utasitasra engedelyezni a mexakitasokat, magyarul felesleges
azokat egymasba agyazni.
Mikrovezerlon ez altalaban nem optimalis, mert nem hasznalunk kernelt.
De akar lehetne is, az egyik projecthez a kollegam irt is egy teljesen
korrekt kernelt, a taszkoktol es memoria-managementtol a grafikus
feluletig (ablakok, gadgetek, touchpanel stb..) mindent megcsinalt.
GCC, AVR, CPLD-s lcd-vezerlo. Az AVR procin ugyanolyan taszk es
interrupt kezeles muxik, mint pl a linux kernelben, allitolag nehany
ora alatt kesz volt a lenyeggel a srac...

> ATMEL eseten kb 13-14MHz felett mar sebessegben felulmulja a 10Mhz 
> 4xPLL PIC18-t. Ugytudom az ATMEGA-k mar 24MHz alkalmazhatokak 
> lesznek. 

Most is van 40MHz-es, csak draga... (FPSLIC)

> Kerdes erdemes nagyobb sebesseg igenyek eseten a 8 bites 
> rendszereknel maradni, valoszinuleg a sebesseg verseny igazi vesztesi 
> a 8 bites rendszerek. Arban azonos LPC2104 es ATMEGA128 de az 

Csak eppen kevesebb periferia, nuku kulso memoria illeszto, keves
belso memoria, stb... Akkor mar inkabb az OKI procik.
Azt legalabb hozza a Chipcad (hurra :), Philipset a Spoerle-tol
vehetsz, csomagolasi egysegben, elso vasarlas min 40 rugo, stb...
Sot, a Chipcad-nel van nehany egesz szimpatikus Cirrus Logic tipus is.
De a 32 bites procik arcsokkenese, ha elterjednek, nyilvan le fogja
nyomni a 8 bites procik arait is. Tehat ahol eddig 8 bites procit
hasznaltunk, oda hasznalhatunk 32 bitest, es ahol eddig pl koltseg
okokbol nem hasznalhattunk semmilyen procit, azt a teruletet
meghodithatjak a 8 bitesek. Ugyhogy nem kell meg kidobni az AVR/PIC
fejlesztorendszereket...
Es ha valaki termeket akar tervezni, tovabbra is megvan a dilemma:
ket perc alatt ossze lehet lapatolni egy mukodo, de eladhatatlanul
draga kutyut draga alkatreszekbol, vagy kicsit tobb meloval egy
ugyanolyan tudasu, de sokkal olcsobb kutyut lehet csinalni.
Kis tulzassal, ha pc-n emulatorban lefut a progi, akkor keszen
vagyunk, tessek pc-t venni a karoratol kezdve mindenhova. Sajnos nem
kutatok, hanem mernokok vagyunk, a feladatunk nem a problema elmeleti
megoldasa, mert azt mar altalaban tobb szaz eve megoldottak elottunk
hires tudosok, nekunk csak meg kell talalnunk az optimalis kompromisszumot
a fejlesztesi ido, alkatreszar, hardver/szoftver kozott, es meg kell
csinalnunk a munkat.
Aki az elso modszert valasztja, jo esellyel soxor pofara fog esni,
amikor a konkurrencia megjelenik a fele aru termekeivel...
Meg az is lehet, hogy 4 bites vezerlo lesz benne. Ha az is eleg...
Nekem ez a C-mania ugy tunik, mint ha azt mondanatok, hogy gyorsan
ossze kell hanyni valami szart, ugy is megveszi a sok balek, felesleges
optimalizalni. Ha nem jo, legfeljebb dragabb procit rakunk ala, majd
kifizetik a vevok. A lenyeg hogy keresunk a neten valami forrast,
addig hackeljuk, mig valahogy sikerul attomkodni a forditon, aztan
megyunk sorozni... Minosegi munka? Ugyan mar...

> univerzalis regiszter amivel kozvetlenul tudok muveletet vegezni (AVR-
> ben ha jol tudom 32 amiben az index regiszterek is benne vannak) a 
> fentmarado regisztereket szinten indirekt modon mint AVR-kben 
> elerhetem. A PIC18 kicsit jobb 3 index regiszter + 96 univerzalis 
> regiszterkent hasznalhato RAM, a tobbi indirekt mint .....

Nem hasznalhato univerzalis regiszterkent. Az AVR minden regisztere
olyan, mint a PIC-ben a W!! A memoria cimzes pedig egy kicsit
korrektebb az AVR-en...
Talan nem veletlen, hogy bar a PIC regebbi, nincs ra normalis C
fordito, pl gcc. Megneztek a GNU-s sracok, es azt mondtak, hogy ezt
inkabb ne eroltessuk... AVR-re egybol megcsinaltak. Az AVR architektura
biztositja a C szamara szukseges kovetelmenyeket, pl normalis cimzesmodok,
linearis, nem lapozgatos cimtartomany stb... A PIC _nem_. Ennyi.
Szerintem asm-ben is eleg nagy kulonbseg van az AVR es a PIC kozott,
C-ben meg nagyobb. A 8 bites procikon amugy is olyan mint egy fel karu
orias, a PIC-en hianyzik mindket karja, a labai, es a feje is :)

> Udv               HG

-- 
Valenta Ferenc <vf at elte.hu>   Visit me at http://ludens.elte.h u/~vf/
"Az eg nem a csillagoknal kezdodik, hanem a fuszalak hegyenel. (J.M.)"