Na TV moc nekoukám, je to často ztráta času. Pokud koukáte ještě ke všemu na takovéto pořady tak budete asi hodně gaučový typ.
Ptal jsem se na AVR32, protože na nich už fungují různé zminimalizované linuxové distribuce.
Architektura řadičů AVR je na jednoduchou automatizaci přímo skvělá, podle mého názoru lepší jak PIC a různé intel kontroléry. S AVR si již pár let tykám a proto mě zajímají i AVR32, které se mi jeví na automatizaci přívěťivější jak ARM, hlavně z hlediska vývoje.
To dělení vlastností (jen 16 registrů, ...) podle názvu attiny/atmega není zrovna moc štastné. Podívejte se třeba na attiny2313, ten má 2KB FLASH, 128B RAM, 128B EEPROM a samozřejmě všech 32 registrů. Nebo ATtiny84 s 8KB FLASH, 512B RAM, 512B EEPROM.
Ale je pravda, že je docela problém se v tom jejich značení orientovat :-)
Skvele clanky !
Len tak dalej.
Uz dlho sa chystam trochu povenovat AVR.
Je z praxe nejaky velky rozdiel (velkost, efektivnost) v generovanom kode pisanom v C pre AVR a v AVR assembleri ? Predsa len dufam, ze ten prekladac bude mat ine kriteria na vysledny kompilovany kod, ako bezne C kompilatory.
C vyplodi kod o neco malo mene efektivni, nez by to udelal prumerny programator v assembleru, kdyby na to mel cas. :)
Casove kriticke rutinu muzes vzdy napsat v assemberu, pokud mas tu potrebu.
Navic za Tebe kompilator udela nektere upravy, ktere by v assembleru mely neprehledny zapis. (c za Tebe rozbali kratke cykly, nahradi procedury makry...)
Ale pokud nedelas zrovna blikac pro decka na stromecek, c je vyrazne prehlednejsi.
Budu se hádat, ale dobrý překladač Cčka dokáže vyrobit kód, který by se mohl srovnávat s profesionálním programátorem v assembleru. Hlavně jakkákoliv další optimalizace by už byla neúměrně drahá.
Trochu lépe jsou na tom šablony v C++, ale jsou to procenta. Soudím hlavně ze zkušenosti,kolikrát musím výsledný kód číst a kolikrát jsou tam obraty, které jsou zaručeně efektivnější a které bych sám asi nevymyslel. Pokud překladač má přehled o celém programu, dokáže kolikrát lépe hospodařit s registry, než člověk, protože nemusí si nikde nechávat rezervu na budoucí rozšíření. Pro stroj není totiž problém kdykoliv nechat kód znovu přeložit na míru, zatímco programátor vždy bude omezen pracností jakéhokoliv budoucího přepisu.
No, hadat se samozrejme muzem, ale zrejme mame jen posunuty prah vnimani. :-) Otazkou je, jestli "profesionalni" programator, kdyz ma dany termin, je lepsi nebo horsi nez prumerny nadsenec jez ma na dany ukol cas. :-D
Zrejme budeme narazet prave na ty mista, kde pisete "neumerne draha".
Proto jsem psal to o tech rozbalenych cyklech a spol.
Ale na druhou stranu jsou konstrukce, kde mam pocit, ze se v C "neumim vyjadrit dost presne".
treba pocitadlo s limitem... (predpoklad: r3=1 ; s oblibou jsem takto obetoval na nulu a jednicku 2 registry r3 a r4 ; ne jak gcc r1, ktery porad pokazde znovu nastavuje... )
add r16,r3
sbc r16,0
Nadherne je na tom to, ze to nepretece a trva to pokazde 2 takty v kteremkoliv pruchodu.
jenze jak to napsat v c (konkretne gcc), aby to pochopilo spravne?
if (r3<255) r3++;
Nemam tu ted po ruce vhodne prostredi, ale necekal bych moc.
Pro puvodniho tazatele bych napsal asi tolik: zalezi na co to chcete, ale v dusledku je dobre umet oboji. :-D Pro slozitejsi veci je prehlednost C k nezaplaceni. Schopnost pouzit assembler pro casove drsne rutiny je ovsem vyhoda.
jeste bych poznamenal, ze jsem pro avr v asm psaval ne pod oficialnim atmelim assemblerem, ale pouzival jsem avra, ktere umelo tuze mile veci s makry (vnorene pripadne i rekurzivni volani maker, volba makra podle parametru a podobne... takze to rozbalovani cyklu slo casto udelat pohodlne).
No prvni pokusy s ethernetem byl zpusob jak najit motivaci ucit se c ... :-D (soucasny stav/moznosti atmeliho avrasm2 jiz nesleduji, necekam zazraky. Gcc mi vyhovuje, merici rutiny si tam v asm doklovu (az) kdyz to potrebuju)
Dovolim si nesouhlasit, protoze blikac s mikroradicem je IMHO jedna z nejlepsich aplikaci, na kterych se muze *zacinajici* programator MCU vyradit a naucit se zaklady. Je to dobra aplikace z vice duvodu:
1) udela fakt velkou botu v programu - nic neblika
2) nespocita si spravne casovani - blika rychle/pomalu (nebo to blikani vubec nebude videt)
3) kazda zmena v programu (zpozdovaci smycce) je ihned viditelna
Co muze byt jednodussiho nez ovladat pres jediny PIN LEDku?
Jinak pro blikani (harmonicky oscilator, ne multivibrator) staci jen jeden tranzistor.
Opatrne panacku. Ta doba je pryc.
V pripade nejakeho AVR osazujes fyzicky 1 cpu , 1 odpor a ledku - a blikas (dobra, muze tam byt navic kond/odpor do resetu, ale jde to i bez toho, pokud mas vhodny programator).
V okamziku, kdy se rozhodnes odblikat pro mne/za mne treba "Lidi zirejte, ja uz to umim!" v morseovce, schema se nemeni. Pripojit dalsi 1-2 ledky porad jde. Kazda muze blikat jinak. Zmena konstrukce minimalni. (ty ledky se srazecim odpurkem) Pripoji jeste pizzak, udela si budik. (na delsi casy krystal a 2 kondy)
Ve Tvem pripade mas 2 tranzistory, 2 kondy, 4 odpory a ledku. Ok? Takze minimalne na osazovne Te poslou nekam, protoze je to zbytecne slozitejsi (drazsi!) na vyrobu. Zmenis maximalne pomer sviceni/tma a to vymenou soucastek. Na nejakou realnou presnost muzes zapomenout.
Z hlediska vyuky programovani je blikani neco, co zacatecnikovi da vysledky. Pokud se UCI programovat cpu (a ne "jen" letovat plech), je cilem naprogramovat cpu, ne zbastlit hnizdo s 2x kc507 z amara.
No ono je tady jeste jedno hledisko. Pokud mi jde o blikani (napr. ten jednoduchy blikac na vanocni stromek), tak mi opravdu staci ty dva tranzistory, dva kondiky a ctyri odpory (pominme fakt, ze to jde udelat jednoduseji). Protoze ke zprovozneni potrebuji "jen" pajecku (+ pajku), popr. nejaky kousek cuprextitu, do ktereho si nozem nebo pilnikem udelam delici cary. Ale da se to udelat treba i na kusu kartonu, zejo :-) Kdezto pro zprovozneni blikace s uCPU budu krome te pajecky potrebovat jeste pocitac, abych ten radic naprogramoval. A to nemluvim o vyrobe plosneho spoje :-). Takze pokud jde o vyuku programovani, neni o cem diskutovat, ale pokud jde o blikani, dva tranzistory mohou byt vyhodnejsi.
ano, ale ta hranice "neotravovat se s cpu" je dnes uz hodne posunuta, protoze prave jeden casto uvazuje tak, ze by to nemuselo "jen" blikat 1:1 a pak se klasicke zapojeni trapne zeslozituje.
Tistak neni problem - pajive bastlpole s ploskama (1-pinove plosky v rozteci dilkoveho svaba) - osadis, uriznes prislusny kousek. :-) V nejhorsim ten brouk otocis hore kotkama, naletujes tu ledku s odporem na to a zalejes tafixem. (sporivejsi totez udelaji na patici za 12kc, aby mohli cpu za 25kc pouzit casem jinak...heh)
Jiste, clovek, ktery nikdy nic neprogramoval a nema vybaveni se nic nepotrebuje (nechce!) ucit.
... a pokud jde skutecne jen o blikani... prodavaji se samostatne blikajici ledky :-D
Dobre, hledim na to. :-( Maloobchodni cena s vysokohorskou prirazkou za kusove mnozstvi je posledni rok, pravda, drsnejsi. Osobne jsem taky samozrejme recykloval co slo. Mne se totiz tykalo jeste postovne. :-) (a to mne jeste obcas drzy bratr urazi cenami, za ktere nakupuje jejich firma v 10k balenich :-D )
Bezkontaktni pole jo, ale konstrukce neni prilis odolna. (na vyzkouseni vyborne, i 20GB barracudu jsem si tak pripojil k mega32 :-P )
Doufam, ze se ceny vrati alespon z casti do normalu... nebo alespon at je to zbozi normalne sehnatelne, kdyz uz to stoji tolik. :-(