PIC MIPS

[hg12345]

Ne legyen flame :-(

> >   
> Persze ezért fejlett :-))
Nem biztos, hogy amit emlitettél nagy elöny és, hogy fejlettebb!

> > A PIC-nek a 1/4 futási sebessége abból adódik, hogy minden 
helyen és 
> > mindenkor tud müveletet végezni a memóriájával. Az AVR és ARM 
> > tjpusú procik utasítás készlete regiszter bázisu, mig a PIC memória 
> > bázisu.
> >   
> Hát.... Azért ez az akkumulátroros móka nem egy leányálom.... Pl. 
> összeadásnál az azért gáz, hogy csak a W regiszteren keresztül 
lehet 
> megtenni.

Miért? 
A regisztereken keresztül jobb?!

Legyen két memóriába csücsülö adatod amit össze kell adni.

A regiszter bázisu utasítás esetén a kód igy nézki:
AVR/ARM :  beolvasom mind két adatot a regiszterekbe majd 
összeadom és tárolom újra a memóriába. 
Ezt kétféle képpen tudom megoldani:
 - mindent beolvasok a memóriába (A és B memoria tömböt) és 
összeadom
 - byte-nként olvasom be a memóriaba összeadom és az eredményt 
tárolom 

A memória szervezésű eszköz esetén (itt szerintem érdemes lenne már 
elfelejteni az akkumulátort, mert nem ez a lényeg)
 - két pointer beállítom csak azt olvasom be amit hozzákell adni a 
másikhoz és elvégzem helyben a müveletet, közben a ponter 
mozgatást is elvégzi.

 Összehasonlitva a két utasitás készlet idejét: Vegyünk egy PIC18-st 
hogy egy sulycsoportba legyenek.
     AVR:  beolvasás *2 + összeadás + tárolás (2x2+1+2=7 óraciklus idö)
    PIC18 beolvasás + összeadás       (2 utasítás => 8 óracilus)
                    movf   POSTINC0,w
                    addwf POSTINC1,f               ;hogy érthető legyen

 Mint látható közel azonos teljesítményt ad a két eszköz. 
 A második tömörebb!

(Egy biztos adatokat valószínüleg minden uP-nel a memóriából kell 
venni és ide kell visszatenni, ez nagy valószínüséggel a közeljövöben 
nem változik :-)


>   
> Értem én, csak alapvetően azt kell észrevenni, hogy ezeket a 
procikat 
> már nem arra tervezik, hogy gépi kódban programozgassa az ember. 


A PIC18-nak a legnagyobb problémája ez, hogy a legelterjedtebb nyelv 
a uC-hez a C (a jogosultsága nem vitás), a PIC18 utasítás készlete a C 
stack relativ cimzéséhez nem éppen elönyös, ráadásul a 3.8K 
memóriaja nem túl böséges egy ilyen kezeléshez. Ugyan az Extended 
utasítás készlet pont ezt támogatja 96 byte hosszuságban szemben 
az ARM 32 cimü relativ cimzésével. Nem akarom dicsérni, nagyon látszik 
a kényszert a megoldáson, a HW stack kezelésre meg nincs megoldás!
Egy uj taszk váltása a teljes HW stack kiolvasásával és ujra 
letöltésével lehetséges és ez több mint idöigényes. :-( Ez az AVR-ben 
szerencsésebb mert a STACK a normál memoriában található és 
elegendö ezt menteni és ujat betölteni a helyére....

Jól 
> lehetett ezt látni mikor kijött az AVR32, a megszellőztetés múlva két 
> nappal már lehetett kapni az IAR-nál a fordítót, debuggert.... Biztos 
> nem 2 nap alatt csinálták :-) Az AVR-nél pedig bevallottan az IAR 
> szakembereinek útmutatása alapján fejlesztették a processzort.
> 

Tudtommal a C egy macronyelv, ha kicseréled a készletet már kész az 
uj implementáció. (Persze egy halom bogarral....)

AVR32 BGA tokozásu, ez amit minden kis cég ültet kis sorozatban 
olcson. :-).

 Üdv
    

_______________________________________________________________________________
MP3 lejátszók már 6900 Ft-tól! A legszélesebb MP3/MP4 video lejátszó választék.
Ingyenes országos házhozszállítás! www.infopatika.hu