Názory k článku Osmibitové mikrořadiče AVR
-
atarist (neregistrovaný)
No kdyz si uvedomim, ze 8051 nemela ani podporu pro signed aritmetiku a pouze jeden indexovy registr, tak si asi ceckovi programatori museli dat velky pozor na to, co pisou, mnohem vetsi nez u CPU ci MCU, ktere jsou pro tento ucel lepe navrzeny. Vlastne si vubec nedokazu predstavit, jak bych na 8051 mel napsat efektivne napriklad konvoluci, a to je pritom docela zakladni algoritmus.
-
Bystroushaak (neregistrovaný)
Jo, ptal jsem se na to v HW konferenci; http://list.hw.cz/pipermail/hw-list/2011-February/389623.html
-
Pavel TišnovskýZlatý podporovatelTa posledni cast odpovedi se mi libila :-)
neco podobneho bylo kdysi davno s pametmi, kdyz vyhorela jedna z mala tovaren na vyrobu DRAM cipu, tak sly tehdejsi SIMMky skokove nahoru (samozrejme jeste byly plny sklady :-)
-
Jirka (neregistrovaný)
jj, tohle mne zrovna postiho - kupoval jsem zrovna počítač (Macintosh IIci) a měl jsem v plánu 16MB RAM (což bylo tehdy na DTP rozumné minimum -stejně, jako zvolený počítač) - a cena pamětí se "ze dne na den" zvedla z 1.000Kč/1MB na 2.000Kč/MB, takže mě tahle událost přišla na 16.000 Kč. Teď už se tomu směju, stejně jako těm cenám v porovnání s dnešními, ale tehdy mě málem kleplo :-)
-
Pavel TišnovskýZlatý podporovatel
Macintosh IIci byl skutecne dobry stroj ve sve dobe. Me ty ceny RAMek taky zasahly (i kdyz "jen" u upgradu o 4 MB), protoze tady byl kazdy zvykly na tu pomerne dlouho platnou rovnici 1MB=1000 Kc.
Tak me napada kdyby bylo mozne v case vratit par dnesnich gigabajtovych DIMMu, clovek by byl milionar :-)
-
Pavel TišnovskýZlatý podporovatel
Jeste abych si pripomenul dobu mladi :-)
IIci jeste akceptoval klasicky 30pinovy SIMMy?
-
Jan (neregistrovaný)
Dražší a nedostatkové. To druhé je rozvedeno zde: http://j.mp/gQZdUZ (z nějakého důvodu je cílový link označen za spam)
Bohužel kdysi výhodná cena je ta tam a 8-bitová řada AVR už z mého pohledu není atraktivní. Řada XMega je trochu nejistý nástupce, HW výbava je ale výborná (ADC + DAC, DMA, Events atd.). V poslední době když hledám nějaký vhodný MCU, třeba na řízení segmentového LCD, tak nacházím stále častěji vhodný typ u konkurence, hlavně Microchipu. A to tvrdím jako zapřísáhlý odpůrce těžkopádné architektury PIC, pro kterou nebyl ani pořádný free kompilátor. Tedy té staré, nyní už jsou k dispozici modernější a schopnější jádra a to za velmi přijatelné ceny.
-
Zdravím, zaujala mne tvoje odpověď. Já zrovna přemýšlím, že bych se alespoň s jedním systémem seznámil a začal jsem uvažovat o AT (ATTiny nebo ATMega), ale trochu jsi mne nalomil. Ještě tedy popřemýšlím.
Myslíš, že tohle: http://www.cesko.host.sk/IgorPlugUSB/IgorPlug-USB%20%28AVR%29_eng.htm by se lépe realizovalo nějakým modernějším PICem? -
avr samozřejmě umí usb, viz např. http://www.atmel.com/dyn/products/product_card.asp?part_id=3874&category_id=163&family_id=607&subfamily_id=760
-
Pavel TišnovskýZlatý podporovatel
Temi modernejsimi PICy mate na mysli uz PIC18 nebo uz ne-osmibitove PIC24 a PIC32?
Me prave PICy prisly dobry hlavne v tech nejmensich radach s par desitkama bajtu pameti a dejme tomu 512 slovy pro program - tam se totiz jeste v tak velke mire neprojevovaly nektere nedostatky instrukcni sady. U vetsich PICu (PIC16, PIC17), ktere vlastne jen rozsiruji sirku adresy, vsak jiz zacinaji problemy se zasobnikem, indirect adresovanim atd. - nic dobreho pro prekladace :-)
Ale uznavam, ze vyber MCU pro amaterske konstrukce je do znacne miry spis otazka osobnich preferenci, ja napriklad v minulosti nemohl prijit na jmeno 68HC11 a tvrde jsem se drzel 51, i kdyz to pri porovnani tvrdych dat melo byt prave naopak :-)
-
klusacek (neregistrovaný)
PIC32 je vlastne MIPS, to uz je zhruba na stejny urovni jako ARM. V necem lepsi nez ARM7TDMI -- na rozdil od nej to ma cache, takze pristupy do pameti vetsinou trvaji 1 takt, v necem horsi -- nema instrukce ldm a stm, takze kod prologu a epilogu funkci zabere vic mista nez v pripade ARMu.
Takze srovnavat PIC32 s PIC18 je priblizne jako srovnavat SGI indy s PMD 85 ;)
-
Pavel TišnovskýZlatý podporovatel
No proto se prave ptam jestli se za terminem "modernější a schopnější jádra" skryvaji jeste osmibitove mikroradice nebo uz mnohem vykonnejsi MCU. To uz by totiz bylo trosku mimo tema techto clanku (i kdyz MIPS je dnes mozna nejpouzivanejsim jadrem pro embedded systemy, tezko rict, kam ho cinani vsude davaji).
-
Aleš Zima (neregistrovaný)
Dobrý den.
Předem bych chtěl poděkovat panu Tišnovskému za pěkné, čtivé články.
Dovolil bych si pouze upozornit na fakt, který není v článku zmíněn, že libovolné použití všech registrů R0 až R31 nelze použít u přímých instrukcí s (8-mi bitovou) konstantou. Jelikož instrukce AVR jsou 16-ti bitové, při použití 8-mi bitové konstanty a 4 bitů pro kód instrukce zbývají již jen 4 bity pro určení cílového registru. Ten tedy může být z rozsahu R16 až R31. Proto u nejmenších AVRtiny, kde jsou registry zredukovány na polovinu, chybí kvůli kompatibilitě právě ta spodní polovina R0 až R15 (a jsou tím též zachovány registrové páry X (R26:R27), Y (R28:R29) a Z (R30:R31)).
S pozdravem
Aleš -
Pavel TišnovskýZlatý podporovatel
Diky za upozorneni, o instrukcich s konstantou jsem se skutecne zapomel zminit. U techto instrukci je zajimave i to, ze na vetsine mikroradicu AVR trvaji dva takty namisto jednoho taktu, coz asi souvisi s tim, ze je nutno pozastavit ALU az do zpracovani instrukcniho kodu radicem (ale mozna je duvod v tomto pripade jiny).
-
Aleš Zima (neregistrovaný)
Ano, máte pravdu. Tyto přímé instrukce ADIW/SBIW (pracující s dvojicí registrů) opravdu trvají 2 takty, narozdíl od těch co operují s jedním registrem a 8-mi bitovou konstantou. Ty samozřejmě trvají pouze 1 takt. U přímých instrukcí pracujících s dvojicí registrů tu je omezení ve velikosti konstanty, která je tvořena již jen šesticí bitů, proto může nabývat hodnoty 0 až 63.
Aleš
-
Pavel TišnovskýZlatý podporovatel
Hmm v predchozi odpovedi jsem dal do jedne vety dohromady dve nesouvisejici informace :-(
Chtel jsem totiz napsat, ze u nekterych instrukci je adresovani registru jeste vice omezene nez jen na R16-R31 a ze tyto instrukce soucasne trvaji dva takty. Jak spravne pisete, jsou to ADIW a SBIW, kde se do 16bitoveho instrukcniho kodu musela nejak vejit jak konstanta, tak i index prvniho registru z registroveho paru.
Nakonec se tam vesla jen sestibitova konstanta a registrovy par je omezen na moznosti 24+25, 26+27, 28+29 a 30+31, coz vlastne neni tak malo, protoze sem padnou i X, Y a Z :-) a pro nejake preskoceni casti pole pri adresovani offset 0-63 nekdy postacuje.
-
Loyssa (neregistrovaný)
Vidím, že je to tu samý doktor inženýr kandidát věd, hoďte sem kousek kódu pro PWM LED flashing. Ledky mám na portu C, už mám úplně "vykoukané" oči, hrozí oslepnutí, jak do toho pořád čumím, a kýžený efekt se mi nedaří stále naprogramovat. Jde mi o takové to pozvolné rozsvěcení a pak pak pomalé zhasínání LED, prostě se mění střída svítí/nesvítí.
-
Pavel TišnovskýZlatý podporovatel
Jestli se nemylim, tak i ATMega32 podporuje PWM, dokonce na ctyrech kanalech. Takze nejake slozite casovani apod. netreba implementovat, jen nastavovat ridici registry PWM. Jeste se na to mrknu a neco poslu...
-
zz_indigo (neregistrovaný)
PWM ide len na niektorych vystupoch (atmega8 je to PB1,PB2,PB3). inak to musis riesit cez prerusenia a "rucne" zhasinanie a rozsvecovanie.
Najjednoduchsia SW metoda na "50%" svietivost:
DDRC=0xFF;
when(1) {
PORTC=0xFF;
_delay_us(50); //Pridavame svetlo
PORTC=0x00;
_delay_us(50); //Uberame svetlo
}Iked ja by som to riesil cez citac ale to uz nieje takto trivialne ale za to moze cpu robit aj nieco ine ;-)
