Dobrý den, chci se zeptat, proč se paměť dat RAM u mikrokontrolérů dělí do bank, a není v celku jako paměť dat EEPROM. Tuto otázku mám jako připomínku k obhajobě maturitní práce. Na internetu jsem bohužel nic konkrétního nenašel. Moje úvaha je taková, že mikrokontroléry jsou 8 bitové, a tím pádem bych mohl adresovat pouze 2 na osmou adres (256). Což je málo, tak se to vyřešilo pomocí bank. Ale nejsem si jist. Děkuji za případnou odpověď.
administrator: přesunuto z "Elektronika s mikrokontroléry, procesory"
32b CortexM0 ma udajne menej tranzistorov ako AVR, takze sa tiez skor priklanam k tej stupidite.
Respektive k terminu “dieta svojej doby”. Ine predstavy a myslenie navrharov bolo koncom 70-tych rokov ked sa rodil PIC (v PIC16 sa bankuje aj programova pamat a treba si to rucne obsluhovat) alebo 8052 ( v ktorej bolo 256B ram a pomaly sa nevedelo co s nou ) a ine zaciatkom 21. storocia.
teoreticky sa umozni rychlejsia praca s pametou a registrami… ak uvazujeme 8b uP stale mozeme adresovat 256B v jednej banke,stranke.
netreaba dlhsie ako 8b slovo na to. Sice vznika otrava sprepinanim ale prepinanie sa nemusi diat stale.
Ak by neboli stranky, na adresovanie by trebalo 2B a viac co by pri 8b uP sposobovalo zdrzanie, pokles vykonosti.
Treba si pozriet architektury procesorov urcite ste to v skole spominali harvardska a intelovska ?
Nemusí tomu tak být. Na to, jesli trvá naadresování paměti 2 nebo 3 cykly se obvykle hledí pouze při optimalizaci v asm. V tomto případě však není problém si dotčené datové pole zarovnat na takovou adresu aby stačilo měnit jen 1B v adresovém registru (u AVR jsou to pointery X, Y, Z s možností postinkrementace a predekermentace). V ten okamžik je po problému.
Já jsem si právě myslel, že kdybych měl právě paměť o 512B, tak by 8 bitový uPC nebyl schopen adresovat vsech 512 míst, protože pomocí 8 bitového čísla můžu adresovat pouze 256 míst a kvůli tomu se vytvořili jednotlivé banky. Ale podle toho co tu píšete to tak není tak teď opravdu nevím .
Samozrejme ze to tak nie je. Adresna zbernica pre RAM alebo pre programovu pamat principialne nesuvisi s tym, ci je procesor 4b, 8b, 16b alebo 32b.
Suvisi to s jeho konstrukciou a vobec nie so sirkou v jednom kroku spracovavaneho slova.
Uz si sa dozvedel, ze so sirkou slova procesora (4b,8b,16b,32b,64b) to nesuvisi. Viac Ti zatial povedat nevieme, lebo si stale neuviedol
o aku procesorovu rodinu sa jedna. Podla toho by mohli byt smerovane odpovede/historicke a kontextove znalosti.
oni sa ta nepytaju preco sa strankuje RAM po 256B, lebo tieto kusky ani 256B RAM nemaju. Podla katalogu len 224B. Co tam chces preboha strankovat.
Oni sa Ta pytaju, preco sa strankuje programova pamat.
No preto, lebo to navrhovo a konstrukcne nezvladli, respektive by som to povazoval za “dieta svojej doby - z konca 70-tych rokov”. S technologiou Flash dalej vyrabaju a zaujemcovia pouzivaju toto tazkopadne a dne viac ako nevhodne riesenie. Medzi nami, nepoznam ziadnu inu rodinu MCU s takto nestastne riesenou adresaciou programovej pamate a ak mozes chod od nej co najskor co najdalej.
Nemyslim si ze sa jedna o bankovanie pamate. Jednoducho su jednotlive pamatove oblasti nejako pridelene. To ale neznamena, ze treba extra zvlast osetrovat stav, ked by program mal pokracovat v dalsej banke a preto si to musi programator (clovek) samostatne osetrit a hlavne ten debilny navrat, ak sa nedajboze z dalsej stranky skace na dalsiu a dalsiu z zavislosti od nejakych podprogramov. To treba este riesit samostatny sw management stacku tych navratovych hodnot programovej stranky/banky.
Pokial viem, takyto debilny management maju iba PIC16 (neviem, ci aj PIC12). PIC18, PIC24 a vyssie by to uz mat nemali. Ale o tom skor napise nejaky PICkar. Tie vyssie PICka maju aj vela inych normalnych vlastnosti, dokonca aj vedia robit instrukciu na takt ako normalny RISC (aj ked asi pomocou PLL, ale hlavne ze to frci normalne) a nie na styri ako tie PIC16-ky.
Ale zaujimalo by ma nejake vysvetlenie PICkara, preco je to strankovanie v PIC16 tak. Urcite by vedel daleko erudovanejsie odpovedat a mozno sa dozvieme nove info z hladiska historickeho vyvoja.
Dle mě jde opravdu o finance. Zhledem k tomu, že PIC16 pochází ze 70. let a měl to být jako programovatelný doplněk k větším bratrům. PIC16 má 14b širokou šířku programového slova.
Kód skoku se skládá z 10b adresy a 4b připadají na samotnou instrukci. Proto jsou stránky v programové paměti rozděleny po 2048 x 14b. Zvětšení šířky na 15b by asi pomohlo, že by se paměť programu nedělila do tolika stránek. Předpokládám, že na toto se tazatel neptal, vzhledem k tomu, že PIC16F628 má jen jednu stránku a nemusí řešit PCLATH.
Zjednodušení ze strany Microchipu je tu asi všem jasné.
Bankování RAM. Taky se šetřilo.
Instrukce které mění obsah nějakého registru - BYTOVÉ instrukce
obsahují 7b adresy cílového registru v RAM
1b co se s tím má dělat - uložit do RAM nebo do W
6b OP kód
U dalších typů instrukcí je to obdobný
Díky tomu stačí zjednodušený řadič RAM, na kterým se ušetří hradla a tím pádem $
A obloukem se dostáváme k tomu, že díky 14b šířce slova se tam toho prostě víc nevešlo.
Když se tam dívám přímo na jednotlivý OP kódy tak teda musím, říct, že je to MCU blbě optimalizovaný.
PIC12 nemá smysl řešit, 12b šířka slova mluví za vše, ale holt je to levný.
PIC16F1xxx je na tom o dost lépe než jeho předchůdce PIC16. Pracuje se mi s tím vcelku dobře, ale na PIC18 to prostě nemá a ani to nebyl záměr.
PIC18 to už v takové míře řešit nemusí díky 16b šířce slova a jiným vylepšením na straně řadiče a dekóderu instrukcí a systému FSR. Tam je dost místa ve slově jak na adresy, tak na data. A když ne tak se použije holt víc paměti, viz. rozdíl GOTO (4B) a BRA (2B)
Jenom bych k tomu podotknul, že zrovna u PIC16F628 se nestránkuje ani programová paměť, protože u těchto malých starých se stránkuje až od 2k (tedy třeba PIC16F648, PIC12F683 atd., ty mají 4k…)
Předpokládám, že se ty banky řeší (pokud opravdu) v asembleru - který zoufalec by programoval PIC 18,24,32 v asembleru? To tak ještě pro ty PIC16 - s 35 instrukcemi.
V tom případě - příjemnou zábavu na dlouhé zimní večery .
I když připouštím že za nějakou delší dobu si každý asemblerář vytvoří své “knihovny funkcí” - tedy podprogramů a maker a může psát stejně rychle jako v Céčku. Ale osobně, třeba takový podprogram pro čtení čidla DS18b20 po 1wire bych v asembelru nechtěl psát ani za zlaté prase .
administrator: přesunuto z "Elektronika s mikrokontroléry, procesory"
) a ine zaciatkom 21. storocia.
.
.