Neeee, mělo to určitě víc než 60MB
poradte mi teda kerou verzi stáhnout… aby teda fachala 
Díkes , Honza
Urcite tu posledni, aspon sem s ni nemel zatim nejmensi problemy.
Kdyby to nahodou nefachalo, tak muzes potom zkusit tu v4.13.528 a na ni dat patch na v4.13.571 (oznacujou to jako SP2). Nicmene ta posledni by mela fachat.
Dostupne verze AVR Studia jsou na atmel.com/dyn/products/tools_card.asp?tool_id=2725
Verze 589 je plně funkční i na XP. Není ani problém s instalací.
Predem PS (jsem malinko vysatej): Ten odkaz na posledni verzi jsem daval uz nekolikrat!!! ANO je to na strankach atmelu (atmel.com)… Kde jinde, kdyz delaj AVR Studio oni…
dostupne verze: atmel.com/dyn/products/tools_card.asp?tool_id=2725
posledni verze (v4.14.589, primej odkaz bez registrace) atmel.com/dyn/resources/prod_documents/aStudio4b589.exe
A kdyby nahodou chtel nekdo vyzkouset TOLIK NENAVIDENE C, tak “sourceforge.net/project/showfiles.php?group_id=68108”… Holt, kdo neokusil, nevi… (zadnej strach, zitra budu slusnej, to jen, ze jsem dnes musel z hospody 4Km na kole, tak mam blbou naladu…)
To je ta verzia 4.14 build 589 co Vam tu stale predostierame.
Za tie pindy o C sa omluvam 
Martin
A kolikarozměrné pole se vejde do AVR s velikostí SRAM pár KB? Céčko dle mých dlouholetých zkušeností není vhodné pro osmibiťáky ať už jde o AVR, PIC nebo x51. Jsou na to příliš malé a používají se spíše jako inteligentní periférie než jako hlavní řídící procesory. Tam se dnes nasazují 32b MCU. Pro ně má Céčko smysl.
Co se týče aritmetiky, v céčku je jednoznačně přehladnější zápis, ale výsledek je nejistý. Pokud používáte pro aritmetické operace pouze signed int, je vše Ok, ale jakmile začnete kombinovat signed s unsigned, word s bytem a intem, není správný výsledek vždy zaručen. Zajímavým případem je rozdělění int na 4 byte a po přenosu např. po RS232 opětné složení na int. Dá se to napsat několika způsoby, ale výsledek nemusí být vždy totožný. Tohle je v ASM úplá sranda a odladí se to hned a bez chyb.
Céčko má své záludnosti a kdo je nezná, má smůlu. Navíc ne všechny překladače jsou podle normy ANSI/ISO, takže stejný zdroják mohou přeložit různě a ty chyby se pak velmi obtížně hledají.
Mozno nejde ani tak o mnohorozmerne polia, ale napriklad o moznost pouzivat struktury a pole struktur sa spravuje v C velmi prehladne a zrozumitelne. Prekladac sa sam stara o umiestnenie lokalnych premennych, da sa viac sustredit na podstatu problemu ako na samotne kodovanie a bude asi jedno kolko malo kB RAM ma procesor k dispozicii.
Samozrejme, ze sa to da spravit v ASM, ale naco (ak sa nejedna o konicek a zalubu - proti gustu ziaden disputat)? V C sa taketo veci omnoho lepsie udrzuju (aj za cenu vacsieho kodu a znizenia rychlosti),tak preco sa tejto vyhody vzdavat? A ak je treba prejst na vykonnejsiu platformu (32b MCU) preco nevyuzit cast hotoveho kodu v C a iba ho rozsirit, miesto kompletneho prepisu aplikacie?
Preco by malo byt spracovanie roznych typov v jednom vyraze v ASM bezpecnejsie a vysledok by mal byt viac zaruceny? C pozna pretypovanie , len ho treba spravne pouzivat. Ale vsetko, co ma davat spravne vysledky treba spravne pouzivat, asi ani ten asembler nebude samospasitelny.
V com je to v C mensia sranda? Uz len slovne spojenie “odladí se to hned a bez chyb” evokuje stav potreby nieco ladit, t.j. nieco nefunguje spravne alebo nie presne ako ma a preto to treba ladit. Ako to moze byt zaroven bez chyb? Jasne, ze ked tvorca zisti, ze nedostava na strane prijmu rovnaku hodnotu aku ma na vysielacej strane, bude hladat co je vo veci. A asi bude jedno ci programuje v C, C++, BasCOM, ASM, ci co ja viem v com.
Neberte prosim moje pripomienky ako vyhrady voci ASM. Tam kde je to vhodne (rychlost a kompaktnost kodu), alebo to niekomu viac vyhovuje,
preco nie. Ale tvrdit, ze pre x51, PIC ci AVR nie je vhodne pouzivat C, lebo tieto procesory maju malo kB RAM (asi sa skor bude jednat o AVR ) sa mi nezda opodstatnene, kedze C nie je navrhnuty prioritne pre to, aby spravoval vela RAMky ale ma mnohe ine vyhody.
Martin
Myslim že rozebírat výhody a nevýhody Cčka tu nemáme, radši mi poraĎte: Zaregistroval jsem se na atmel.com, stáhnul jsem si AVR tudio 4.14, tedy to nejnovější.
Učim se s tim podle helpu, zas tak složitý to není. Zkopíroval jsem tam jeden progrrámek z netu, konkrétně tento: programujte.com/index.php?akce=clanek&cl=2006070301-avr-%96-blikame
Překompiloval jsem to, a nyní si hraju s debugerem/simulátorem.
Po obědě si udělám svůj prográmek, na blikání LED.
Nemáte někdo instrukční soubor v češtině?? S angličtinou zas problémy tolik nemám, ale včeštině by mi to bodlo
Díky, Honza
Bohuzel, jedinej castecne ceskej popis, co mam uz tu je na prvni strance (pr06_IS_AVR.pdf).
Jo díky, už semto kdysi stáhnul. Je to tam popsané celkem slušně, aspoň jsem trochu z toho pochopil, jak je to s instrukcemi BRxx
Momentálně se pokusim vyrobit prográmek na blikání LED, pak napíšu jaký byl úspěch.
Jo, a ještě dotaz, když budu chtít utvořit spožďovací smyčku, to jí po každé vymýšlítez hlavy, nebo na to existuje nějakej soft co to vymyslí za vás??
EDIT: Ještě by mě zajímala jedna věc: Když mám port u AVR nastavený jako výstupní, a je na něm logická 1, mohu ten pin uzemnit? Protože u x51 to jde, tak se radši ptám, abych něco neodpálil…)
Díky, Honza
Tady to nejde, kdyz je port jako vystup, tak je rizenej tranzistorem do 1 i do 0(x51 ma pull-upy pro 1 a tranzistor pro 0).
Pouze kdyz je jako vstup, muzes si pull-upy(20-60k) zapnout tim, ze na ten port(piny) zapises “1”.
Na zpozdeni pouzivam casovace, pouze vyjimecne for (v C), ale pak se musej vypnout optimalizace (coz je stejne dost casto potreba).
Programek muzu zkusit napsat, ale bude to v C#, takze je na stroji potreba .NET 2.0, pripadne to pak muzu predelat do php, ale to by sis musel najit web. prostor, kde to budes mit 
ad php, lol, web server mám dá se říct svůj, no problem, ale větší problém, že po Cčku neprahnu.
A další věc, neřek bych že to těch časovačů má nějak nazbyt…
si nikdy nepotřeboval spožďovací smyčku?? 
EDIT: nebo myslel jsi jako že bys mi napsal aplikaci na vytváření zpožďovaček?
Momentálně se jí snažim vymyslet, ale moc mi to nejde 
UGH, FUJ to byla práce… (po dvou hodinách!!!) Vymyslel sem vzorec pro výpočet jednostupňové zpožďovací smyčky:
ldi R16, X
on1: dec R16
brne on1
C = 3*X, kde C je počet tiků xtalu.
a vzorec pro dvoustupňovou kaskádní:
zpozdi: ldi R16, X
on1: ldi R17, Y
on2: dec R17
brne on2
dec R16
brne on1
ret
C = 3X + X3*Y
ještě to vymyslim na více stupňové
jj, programek, kterej vytvori avr-asm kod, kterej se vlozi do zdrojaku.
Neco jako toto:
[code];nutna inicializace zasobniku
.
.
call Delay ;4/5
.
.
;-------------------------------
;DELAY soubroutine, time: x us
;XTAL: x MHz, x machine cycles
;used registers: sreg, r16
;-------------------------------
Delay: push sreg ;2, none
push r16 ;2, none
ldi r16, k1 ;1, none
loop_d1:
dec r16 ;1, Z,N,V,S
brne loop_d1 ;1 bez skoku/2 se skokem, none
nop ;1
pop r16 ;2, none
pop sreg ;2, none
ret ;4/5
;-------------------------------
;end of DELAY soubroutine
;-------------------------------[/code]
Jen jeste musim doresit, ze “call” nemaji vsechny avr-ka a push/pop sreg mi to taky nebere… asi jsou to dost trapny problemy, ale avr-asm bezne nedelam, tak si jeste musim neco dostudovat
sreg treba ulozit a potom obnovit z/do nejakeho registra, napr do r0, r1, r2 atd. a nie pomocou push/pop sreg!!!
jj, taky jsem na to uz prisel… ale dik a misto call bude rcall…
SREG aneb PSW šlo přímo pushnout/popnout u x51 
Jinak přišel si na to taky, jedině dobře
jak nektery avr nemaj call? čim teda volaj podprogramy? nebo maj jenom rcall?
Teraz som pozeral datasheet ATtiny2313, ATmega8, ATmega162 pricom, instrukciu CALL ma az ATmega162 a ostatne dva mcu maju len Relative Call - RCALL a Indirect Call - ICALL. Podobne je to aj s instrukciami RJMP resp JMP
jj, treba mega8 ma jen rcall, a kdyz nedoskoci, musis si skocit na skok
EDIT: hmm… pozde, kado me predbehl…