A topicindító egy PIC12F675-ről beszélt
Itt kezdődik az agyrák. ;) Sajnos az ebay és tsai néha kifejezetten ósdi típusokat árulnak, pontosan azért, mert jó régen lelkes amatőrök ezekkel dolgoztak ki (akkor) egy csomó érdekes és hasznos (bitbang) megoldást. Mindeközben a PIC16 családban (ami nem a legfejlettebb 8 bites) rengeteg új típust hoznak ki még manapság is. Ennek pontosan az az oka, hogy itt nem az FPU-k száma, vagy az ethernet ínterfészek sokasága a választás szempontja, mert nem arra való. Szintén kutya nem akar egy vezérlési célra szerkesztett mikrokontrollerrel webszervert csinálni, vagy dataflow processzort játszani, mert arra sem való. De ha PID kontroller libet linkelnél, akkor helyette választhatsz PID kontroller math engine-t tartalmazó PIC16 modellt. Nincs benne FPU, de a 30 bites (asszem) számításokat kiválóan végzi hardverből. A PIC18 bizony tartalmaz hardver szorzót. (RISC == FPU ???)
- már mondtam: az indirekt címzés maga a megtestesült gányolás
Biztosan, bár pont olyan, mint az x86-ban, esetleg többet is tud. :)
- nincsenek regiszterek, van a W és gyakorlatilag annyi
Bizony, nem egy sokregiszteres eszköz. Pedig már korábban is írtam, de mégegyszer nem számolom ki: kb. 276 címet tud elérni ez a szegényes megoldás, amíg egy "sokkal jobb" talán 20-at. Ez azért van, mert ez egy "register file" szervezésű CPU - de nevezhetjük gyostárnak is. Azt a műveletet amit a W (legyen most akkumulátor) el tud végezni, azt általában bármelyik megcímezhető entitással is működik. Ettől risc a risc ebben az esetben, mert "akárminek az elérésére is" ugyanazt az utasítást kell használni.
- a programmemória is lapokra van osztva
Nincs, legfeljebb több részre hívatkozhatsz pl. védelmi biteknél. Egyébként teljesen folyamatos a címzése. PIC18-tól (ha kell, ha nem) már 24bites a címzés, amivel a flash írható-olvasható.
a memory bankok, amiket manuálisan kell váltogass
Ezt egy kicsit szokni kell, de némi ész meg a fordító sokat segíthet. Ez az ára annak, hogy az utasítások rövidek, így az opcode kevés címbitet tartalmazhat. Ettől viszont sokkal gyorsabb lesz. A sok SFR is több lapon helyezkedhet el, de a gyakran használt regisztereket általában egyszerűsítve direkt is elérheted.
na de pontosan mivel nem értesz egyet, azok közül, amit írtam? + tényleg azért kell fizetni a mplab proért, mert nem fontos az optimalizáció. és ti azért nyomjátok a assembly-t, mert attól
gyors leszbelefér abba a spórlós rom-ba.
Achtung! Magánvélemény következik.
- Bár PIC18-tól az architektúra C-re készült - mármint van egy extended mód és utasításkészlet is. Szerintem ez csak a C-hez ragaszkodó, kis processzoron bazinagy projekt szemléletű emberkék kedvéért létezik. Vagy akik nem tudják kiválasztani a megfelelő modellt, ezért "hordozható" kódot szeretnének írni. Szerintem ez a szint inkább firmware. Nekem viszont nem okoz gondot az awk vagy C közvetlen assembler kóddá alakítása. Természetesen ilyenkor pl. nem az FPU megléte az alapfeltétel, sőt webszerver sem készül.
azért nyomjátok a assembly-t, mert attól
gyors leszbelefér abba a spórlós rom-ba
Szerencséd, hogy áthúztad. Az csak a naívak elképzelése, hogy az assembly a sebessége miatt jó. Ha tudod mit csinálsz, akkor a C is pontosan olyan gyors. Pl. ne írjál stack igényes C programot egy PIC18-ra, mert ott bizony a stack csak egy szoftveres emuláció és ennek megfelelően igen lassú! A rom nem spórolós, csak nem megfelelő modellt választottál, vagy túl nagy feladatot próbálsz bepréselni a nemlétező helyre.
Pl. én a legtöbb munkát PC18F24K50-en végeztem (16kB) és a "nagy" program 8k feletti. Ha megszorulnék, akkor van 25K50 (32kB).
Hasonló a PIC18F2[456]J50, ahol 10k a program, a három modellben 16/32/64kB flash van. Az utóbbiba már bazinagy program is belefér.