A ještě poznámka k té knize-je to jen český překlad manuálu CV doplněný o pár dalších informací. Je to tam i v úvodu zmíněné. Tam opravdu nikdo nebude řešit jaký odpor a jakou ledku, nebo čím dostaneš program do procesoru, natož pak pak nějaké pojistky, či periferie mikrokontroleru. Na to je opravdu dobrá ta Divousem doporučená kniha, ale hlavně datasheety.
Budu opakovat po sté to co tu psali i jiní, (ale opakování je matka moudrosti)
nauč se používat dasheet bez toho se prostě neobejdeš chceš li dělat i něco jiného než jen blikat ledkama. A protože ses tu zajímal o komunikaci s SD kartami tak určitě chceš. 
Toto bych potřeboval ale já nemám nárok z rapidshare.com něco stáhnout kdyby to bylo někde jinde tak bych to uvítal díky.
pokus.omyl: tím **tu jsem myslel fórum , ne jen toto téma
meloun: stačí kliknout na “free user” , nebo v obsahu fóra je taková sekce…
**
Tím “tohle” jsem myslel ten DASHEET, když už něco zvýrazníš červeně, tak by to možná chtělo si to ještě jednou po sobě přečíst 
Ale co, stane se, jsme jen lidi… (a pokud jsi myslel datasheet, tak máš samozřejmě pravdu, bez toho to většinou nejde)
Tak v tom případě:
ulozto.cz/2613862/atmel-avr-at-mega16.pdf
administrator: příspěvek byl upraven
Citace byla pozměněna.
Tak už jsem na to narazil kde dělám v syntaxi chyby? díky.
[code]#include <mega8.h>
#define xtal 8000000
#define LCD_RW 1 // sem vzdy napiseme bit, na ktery je dany signal na portu pripojen
#define LCD_E 2
#define LCD_RS 3
#define LCD_D4 4
#define LCD_D5 5
#define LCD_D6 6
#define LCD_D7 7
#define LCP PORTD // nadefinujeme port kam je LCD pripojeno
#define LCDR DDRD // nadefinujeme smerovy registr pro LCD
#include <Delay.h>
int LCD;
unsigned char vystupLED1;
unsigned char vystupLED2;
void PosliPrikazLCD(uint8_t cmd) //v proměnné cmd máme poslaný typ příkazu
{
LCD=(cmd&0b11110000); // pro nastaveni pouzijeme jen 4-bity
LCD|=1<<LCD_E; // cvaknem E signalem
delay_ms(1);
LCD&=~(1<<LCD_E);
delay_ms(1); // pokazde pockame, displej ma pomaly procesor
LCD=((cmd&0b00001111)<<4); // nastavime zbyle 4-bity
LCD|=1<<LCD_E;
delay_ms(1);
LCD&=~(1<<LCD_E);
delay_ms(1); // a zase jsme zacvakali E signalem
}
void main(void)
{
DDRC=0xff;
vystupLED1=0x55;
vystupLED2=0xAA;
while (1)
{
delay_ms(500);
PORTC=vystupLED1;
delay_ms(500);
PORTC=vystupLED2;
}
}[/code]
Nejdřív zkus řádek “void PosliPrikazLCD(uint8_t cmd)” upravit na “void PosliPrikazLCD(unsigned char cmd)” (nevím jesli CV zná uint8_t).
Další chyba je v logické operaci provedené nad různými bitovými šířkami. To by se dalo vyřešit přetypováním, ale spíš mi není jasná jiná věc.
Neměly by se operace ve funkci “void PosliPrikazLCD(uint8_t cmd)” provádět s portem namísto s proměnnou? Pak bys místo LCD=… atd. měl mít LCP…
Pleteš hrušky s jabkama - konkrétně časti z CV a části z GNU - máš tam od někud zkopírovanu rutinu pro inicializaci displeje, který pak ale nepoužíváš naívíc úplně zbytečnou - CV má pro LCD knihovnu to celé obstará jediný příkaz lcd_init();. To je vše v té knize co sis pořídil popsané a mě připadá žes ji snad ani neotevřel. 
Ano ten úryvek programu jsem překopíroval z mcu.cz/news.php?extend.1871.3 já myslel že Céčko je jen jedno a teď zjišťuji že je v tom pěkný “hokej” nebo spíš já ho mám 
díky
pro piityy ten první typ byl dobrý tak už mi to hází
Warning: C:\cvavreval\priklady\program1.c(24): overflow is possible in 8 bit shift left, casting shifted operand to 'int' may be required
díky
No dobře ale stejně pořád nerozumím tomu - proč sis překopíroval do programu kde blikáš ledkama inicializaci LCD displeje.
Céčko je opravdu jen jedno a stím ANSI-C jak ho tu zdůrazňoval pityy můžeš psát ve všech kompilérech a pokud jde o zápis datového typu - char nebo int8_t - ten druhý můžeš samozřejmě používat v CV taky - jen musíš dát #include <stdint.h> což GCC dělá taky - jenom automaticky při založení projektu - stejně jako v GCC je možné psát tvary char a int
A ještě poznamka pityymu - CV má taky header io.h -ten samý jako GCC - taky si umí najít header příslušející každému jednotlivému typu - který musíš ovšem někde definovat a to stejně u CV i GCC při zakládání projektu 
čím déle se zabývám porovnáváním obou kompilérů tím více zjišťuju že jsou vlastně úplně stejné - snad jen ten trošku vymakanější přístup k jednotlivým bitům portů u CV
Doufám pityy, že tedy snad vezmeš Codevision na milost a přestaneš ho kritizovat vždy když o něm padne zmínka
Meloun: A ty tam máš ten displej opravdu připojen? Na blikání ledkama je tam skutečně většina kódu zbytečná, stačilo by [code]#include <mega8.h>
#define xtal 8000000
#include <Delay.h>
unsigned char vystupLED1;
unsigned char vystupLED2;
void main(void)
{
DDRC=0xff;
vystupLED1=0x55;
vystupLED2=0xAA;
while (1)
{
delay_ms(500);
PORTC=vystupLED1;
delay_ms(500);
PORTC=vystupLED2;
}
}[/code] a ani ty proměnný tam nejsou potřeba. Jinak samozřejmě teď ti to hází jen varování o možném přetečení při shiftu před jeho uložením do větší proměnný, což ale tady není problém.
Nicméně když se toho varování budeš chtít zbavit, uprav “LCD=((cmd&0b00001111)<<4);” na LCD=((((int)cmd) & 0x0F)<<4);
Každopádně jak jsem psal minule - ty operace mají být pravděpodobně s portem, nikoli s proměnnou LCD. Jinak se jen bude měnit proměnná, ale do displeje se ti nic nepošle (jesli ho tam tedy máš).
lou: Většinou(doufám) ani tak nekritizuju CV, jako spíš ten kód, který pisatel uvede a je ho to schopno přeložit. Ve světě jednočipů jsou věci, které C zkrátka nepostihuje a musejí být řešeny nějakou nástavbou nad C - např. přerušení, eeprom na malých jednočipech(ovšem třeba u ARMu je snad eeprom korektně v lineárním adresovém prostoru). Výrobci některých překladačů své výtvory ovšem rozšiřují i o řešení, která lze v C korektně napsat a tyto doplňky nejsou mezi překladači kompatibilní. Snažím se pisatele tlačit k minimalizaci používání těch nekompatibilních konstrukcí překladačů.
Naneštěstí si někteří výrobci vytvoří takové rozšíření bez toho aby se obtěžovali vytvořit i jeho optimalizovanou verzi pro C korektní zápis
Příkladem budiž v Keilu pro x51 práce s 1bitem (pinem) v bitovém rozsahu (io porty, bitové pole v paměti, registry). Jelis se nepletu, tak C zná POUZE vícebitové číselné datové typy (není řeč o C++, žádný bit, bool, string…) a ejhle v keilu znají typ sbit .
Když použiješ deklaraci “sbit LED2 = P2^2;” a pak “LED2 = 1;”, je použita rychlá “atomic” operace s pinem, ovšem použití (“mého oblíbeného” a všeobecně funkčního) “P2 |= (1<<2);” vede na pomalejší a “non-atomic” logickou operaci(načtení, or, zápis).
Mimochodem - nějak jsme mimo téma (i s melounovým programem, teď už to není moc o náhradě procesoru…)
Zatím ještě nemám nic žádný displej prostě učím se Céčko a že pletu dva programy do jednoho projektu protože nechci zakládat více projektů protože by jsem měl pak s toho "guláš"díky.
Na zaklade coho tvrdis take nezmysly? Vyskusal si si to?
To, ze CV potrebuje rozne barlicky a este si za to chce nechat platit je predsa jeho vec 
Normalny prekladac (napriklad GCC) prelozi Tebou deklarovany zdrojak uplne efektivne a atomicky - ak sa to teda da.
zdrojak
int main(void)
{
DDRB = 0xff;
for (;;) {
if (stav_pin == 0x00) {
PORTB |= (1<<2);
}
else {
PORTB &= ~(1<<2);
}
}
}
fragment prelozeneho kodu (-Os)
15: {
+00000024: EF8F SER R24 Set Register
+00000025: BB87 OUT 0x17,R24 Out to I/O location
21: if (stav_pin == 0x00) {
+00000026: 91800060 LDS R24,0x0060 Load direct from data space
+00000028: 2388 TST R24 Test for Zero or Minus
+00000029: F411 BRNE PC+0x03 Branch if not equal
22: PORTB |= (1<<2);
+0000002A: 9AC2 SBI 0x18,2 Set bit in I/O register
+0000002B: CFFA RJMP PC-0x0005 Relative jump
25: PORTB &= ~(1<<2);
+0000002C: 98C2 CBI 0x18,2 Clear bit in I/O register
+0000002D: CFF8 RJMP PC-0x0007 Relative jump
Netvrdim, ze hociaky prekladac vzdy vsetko prelozi najsam super a GCC urcite tiez nie. Iak by nevznikla empiricka skusenost, ze program v C je cca 2x pomalsi a cca 2x vacsi ako program napisany v ASM najspickovejsim ASM programatorom. Druha vec ako by bol taky program v ASM aj udrzovatelny.
Ale take zakladne veci ako manipulacia s bitmi na porte je pre GCC malina.
Martine! Že ty jsi pil U toho příkladu byla řeč o Keilu pro x51. A ANO, vyzkoušel jsem si to, protože na 48MHz jednocyklovém x51 od Silabs píšu diagnostiku do radaru (mimochodem mají i 100MHz kousky). Ta nedořešená optimalizace přístupu k 1 pinu se GCC ani CV netýká.
Nepil. Tema sa tyka AT90S8515 a stale dokola sa tu omiela miesanie kodu CV a GCC:-)
Ak sa chcete bavit o Kiele na x51 zalozte si samostatne vlakno. Do toho kybicovat nebudem.
To, ze sa cela tema tyka CV a GCC a ATmega a niekto niekde medzi recou spomenie Kiela na x51 predsa neznamena ze sa cela tema switchla na x51! Mne z prispevku vyplyynula navaznost na CV a GCC. I ked spomenuta cez Kiel. Ale Kiel je aj na ATmega. Ak Kiel na x51 nieco preklada skrabanim sa okolo celej hlavy, treba to uvadzat do sekcie x51. Ak to robi i pre procesory AVR, spomenut to tu je na mieste a dokonca ocakavane.
Aspon si myslim
Preto moja reakcia na pindy ako ze apriori sa neatomicky prelozi kod
P2 |= (1<<2);pre tu nastolenu temu musim opat zdoraznit, ze tiez tu spomynane GCC (neviem, ze by GCC bolo na x51 ) tento fragment prelozi atomicky, skratka tak ako ma
Ak to Kiel nevie v ramci klasickeho zapisu C a potrebuje barlicky ako CV, je to jeho problem.
P.S. To, ze silabs bezi na 100MHz viem uz dlhe roky. Nic to vsak nemeni na veci, ze su to hriesne drahe procesory s vykonom velmi obmedzenym v dosledku architektury x51.
Chapem firmy, co pre take projekty pouzivaju starucku architekturu x51 (a ani 10 registrov pre pristup k externej pamati ich nezachrani ). Dnes by snad bolo nacim aplikovat niektory z 32b ARMov.
Ale toto vsetko by som neplietol do temy, ci m nahradit AT90S8515.
V tomto smere by som doporucil ze urcite nie ATmega8515, ale treba sa sustredit na ATmega32 alebo ATmega644P. Pozor, ATmega644 je nieco velmi ine .
V tom přípěvku jsem odpovídal na dotaz k tématu, mimo jiné jsem odpovídal louovi nikoli o gcc nebo cv, nýbrž obecně a že byl příklad pro keil a x51 je tam jasně napsáno stejně tak jako že jsme trochu mimo téma. Celé to mělo vést k tomu, že je celkem užitečné při psaní programu v C držet se jazyka dokud to je možné. Řekl bych že jako zkušenější pisatel se také budeš snažit držet hw specifické části kódu (což jsou většinou právě ty nástavby) pohromadě pro snazší udržovatelnost kódu. Nevím co je na tom nepochopitelné. Přijde mi to jako obecná věc a stejně jsem se ten text snažil naladit. Nezdálo se mi tedy později to, že jsi mi předhodil překlad z CV (o kterém vím, že to přeloží správně - mimo jiné od loua z předchozí debaty), o kterém nebyla v příkladu řeč. Příště se polepším a příklad raději uvádět nebudu. Vědět co z toho vznikne, tak jsem si to odpustil celé .
Meloun: Už blikáš?
Absolutne s Tebou suhlasim a to co pises na fore v tomto smere mozem iba podporit. Vseliake tie pazapisy ktore sa zaciatocnici ucia su neskor na skodu a vedu k velmi zle prenositelnemu kodu.
No vidis, ake je jednoduche nadobudnut z prispevku iny dojem, ako ho pisatel zamyslal. Ja som Tvoj prispevok s castou o nastaveni pinu portu pochopil ako popis vseobecnej vlastnosti prekladaca jazyka C.
No a Ty si nadobudol z mojho prispevku dojem, ze pisem o CV, pricom som niekolko krat pisal, ze sa jedna o vlastnost GCC a nie CV . S CV nerobim.
To by bola chyba! Ako by sa inak nejaky zaciatocnik dozvedel, ze existuju prekladace ktore vedia dodrzat C-ckovy zapis a - aj ked to moze byt neocakavane - vygeneruju optimalny kod.
Tesim sa na dalsie diskusie.