Začátečník s GCC - Jaký tutoriál?

Ja viem, ze sa to nezda, ale pouzivat casove slucky na generovanie casu je divne. Aj na tu LEDku.
Ja by som Ti doporucil sa na casove slucky (asi iba s vynimkou 1-wire, tam je to bez nich kvoli kratkym casom velmi osemetne :slight_smile:) hned na zaciatku vykaslat a pouzit nieco, co ti zabezpeci “presny cas”. A medzi tym, nech sa robi nieco poriadne. A nemusi sa jednoat hned o prerusenie

// mega32, blikanie LEDkou

#define PREDVOLBA_ZAP 1000
#define PREDVOLBA_VYP 2000

#define TLED 2 //  napriklad na pine 2 portu B
#define OUT_LED (DDRB |=(1<<TLED))
#define SET_LED (PORTB |=(1<<TLED))
#define RES_LED (PORTB &=~(1<<TLED))

#define PREDDELIC_HLAVNEJ_CINNOSTI 1000
static uint8_t stav_led;
static uint16_t cnt_hlavnej_cinnosti;
int main(void) 

{
	OUT_TLED;
	// prednastavenie modu citaca pocitania do hodnoty v OCR a nastavenie casovej zakladne

	TCCR1B = (1<<WGM12) + (1<<CS10) + (1<<CS12);
	// prednastavenie prvej casovej zakladni
	OCR1A = PREDVOLBA_ZAP;
	stav_led =  FALSE;
   cnt_hlavnej_cinnosti = PREDDELIC_HLAVNEJ_CINNOSTI;
	for(;;) {
		// testovanie dosiahnutia hodnoty citaca v OCR0
		if (TIFR & (1<<OCF1A)) {
			// vynulovanie flag, musi sa pomocou logickej funkcie or |
			TIFR = TIFR | (1<<OCF1A);

// ---------------- zaciatok likania LEDkou -------------------
			if (stav_led == TRUE) {
				stav_led = FALSE;
                                 // _ZAP, _VYP uz podla toho ako mas naletovanu LEDku
				OCR1A = PREDVOLBA_ZAP;
				RES_TLED;
			}
			else {
				stav_led = TRUE;
				OCR1A = PREDVOLBA_VYP;
				SET_TLED;
			}
// ---------------- koniec likania LEDkou -------------------

// tu sa moze robit nieco uzitocne, naprikad nacitavat tlacitko, ako to ze ma ta LEDka vlastne blikat, alebo nieco ine
                        cnt_hlavnej_cinnosti--;
                        if (cnt_hlavnej_cinnosti == 0) {
                            cnt_hlavnej_cinnosti = PREDDELIC_HLAVNEJ_CINNOSTI;
                            fn_hlavna_cinnost(); 
                        }
		}
	}
}

Lahko si zmenis casovac, alebo predvolby.

fn_hlavna_cinnost()

sa prirodzene musi stihnut do dalsieho dosiahnutia predvolby OCR1A casovacom. Inak by sa to muselo riesit cez prerusenie. Ale to je jasna vec.

ak by si chcel predsa len nejake delay, tak prikladam kod,ktory som stiahol tu niekde z webu. Autora nepoznam, ale dufam, ze mi bude odpustene :slight_smile:

Re: AVR - na optimalizaci nezávislé Delay rutiny
Posted: Wed 19 of Dec, 2007 [22:58],
Tiez som s tym bojoval, az som si urobil vlastne... (mikrosekundovu som prevzal a upravil)

// delay for a minimum of <us> microseconds 
// the time resolution is dependent on the time the loop takes 
// e.g. with 4Mhz and 4 cycles per loop, the resolution is 1 us 
void delay_us(WORD time_us) 
{
WORD delay_loops, dummy;
	
	// one loop takes 4 cpu cycles 
	delay_loops = (time_us / 4) * CYCLES_PER_US; 

	asm volatile ("\n"
                  "mov %A0, %A1\n\t"
                  "mov %B0, %B1\n"
                  "L_dl2%=:\n\t"
                  "sbiw %A0, 1\n\t"
                  "brne L_dl2%=\n\t"
				  :"=&w" (dummy) //& znaci, ze sa pouzije len register
                  :"r"((unsigned short) (delay_loops))
	);
}

void delay_ms(WORD time_ms)
{
WORD loops, reminder, i;
	if(time_ms < 256)
		delay_ms_max255((unsigned char)time_ms);
	else
	{
		loops = time_ms / 255;
		reminder = time_ms % 255;
		for(i=loops; i; i-- )
		{
			delay_ms_max255(255);
		}
		delay_ms_max255((unsigned char)reminder);
	}
}

void delay_ms_max255(BYTE time_ms)
{
WORD delay_count = F_CPU / 4000;
WORD cnt;

	if(!time_ms)			//test na 0, zaberie 2 instrukcie, ale pomoze
		return;				//lebo by sa cyklilo 255 krat 
	
	asm volatile ("\n"
                  "L_dl1%=:\n\t"
                  "mov %A0, %A2\n\t"
                  "mov %B0, %B2\n"
                  "L_dl2%=:\n\t"
                  "sbiw %A0, 1\n\t"
                  "brne L_dl2%=\n\t"
                  "dec %1\n\t" "brne L_dl1%=\n\t":"=&w" (cnt)
                  :"r"(time_ms), "r"((unsigned short) (delay_count))
	);
}

Ale já vim jak používat časovač. Klidně si to naprogramuju, to bez problému. Já chci nějaký “delay” třeba kvůli tomu, až budu psát komunikaci pro LCD (HD44780). Nebo si myslíš, že na čekání 40us je také lepší použít časovač? Já si to nemyslím.
A druhá věc je ta, že pokud budu to Cčko vysvětlovat třeba nějakému začátečníkovi, tak pochybuju, že mu hnedka vysvětlím, co je to přerušení a časovač. Já mám zrovna to štěstí, že jsem programoval už dlouho před tím, tudíž mi to pochopit nedělá potíže, ale někomu by mohlo. Ale tohle tu řešit nebudem.

Jen co zprovozním nějaký zdroj k notesovi, hnedka si s tím Cčkem pořádně pohraju. Takle si můžu prohlížet ty programy leda tak v simulátoru…

Ja si to tiez nemyslim a sam som uviedol priklad 1-wire, treba citat poriadne. Preto som ti tam aj tie rutiny v druhom kode hodil :slight_smile:

Uvadzal si priklad s LEDkou a s potrebou generovat relativne dost dlhy cas.
Na to som reagoval s tym casovacom - priklad v prvom kode.
Tam sa mi “delay” zda byt trochu dost zabijak casu. Aj ked verim, ze na odskusanie moze byt :slight_smile:
Drzim palce so zdrojom.

Já právě nevěděl (a furt nevim) co je ten zmiňovaný 1-wire (jednodrát?)
H.

Firma DALLAS vymyslela take speci jednovodicove (hehe ze jednovodicove, vzdy je k tomu treba pouzit aspon GND) rozhranie pre klucenky. No a to rozhranie je 1-wire. Komunikuju cez neho napr.teplomery 18B20 (inak mimochodom papierovo asi najpresnejsie bezne zohnatelne snimace teploty v sirokom rozsahu teplot), uz spomenute buttony - klucenky pre pristupove systemy. Ale robia sa aj AD/DA, EEPROM, myslim, ze aj RTC, atd atd. Suciastky mozu byt napajane aj tzv. parazitnym napatim z rozhrania.

blizsie asi

aag.com.mx/aagusa/contents/en-us/AN126.pdf

maxim-ic.com/design_guides/e … UCTS_4.pdf

wulfden.org/downloads/datasheets/DS18B20.pdf

:arrow_right: administrator: přiloženy externí soubory
AN126.pdf (135 KB)
1_WIRE_PRODUCTS_4.pdf (616 KB)
DS18B20.pdf (227 KB)

No jo, to ja se eště k teplotním čidlům nedostal… Takže jsem toto neřešil, ale třebas to zkusím,… Nevim kolik ty dalasy stojej, ale 100ku za jedno čidloo nedám, protože nemám. Jediné co jsem zkoušel bylo nějaké teplotní čidlo LMxxx, na ot trojšíslí si už nevzpomenu. Lineární čidlo, které jsem vzorkoval pomocí ADC.
Zejtra prověrám pořádně to Cčko… Zkusim napsat něco složitějšího. Momentálně mám v plánu dělat čítač do 30MHz, tak to zkusim napsat v Cčku, uvidíme, jak to půjde.

18B20 v TME stoji 36CZK (bez registracie) v kusovom mnozstve.
Na rozdiel od LM334 a LM335, ktore maju pociatocnu presnost cca +/-3°C az +/-6°C a musis ich nakalibrovat, napr. podla:

jaycar.co.nz/images_uploaded/LM134.PDF

ma 18B20 priamo cislicovy vystup presnostou 0,5°C
Naprogramovat tu komunikaciu je trocha haluz - ak ju neokopcis z nejakeho C-ckoveho projektu, ale potom ta presnost stoji za to.
Pekne je vidiet, ako sa sprava teplota ak je cislo na krabicke, v krabicke s prieduchmi, alebo mimo krabicky. S priebehom teploty v priestore je to vzdy haluz a kalibrovat tie analogove cipy je dost tazke s presnostou viac ako +/-(1-2)°C a to aj v pracovni na stole. Hovorim to z vlastnej skusenosti.

Ale ako pises, vsetko ma svoj cas, tak ti drzim palce.

:arrow_right: administrator: přiloženy externí soubory
LM134.PDF (274 KB)

Nooo… řeknu to takle. Je mi jedno kolik to stojí v TME, pač tam je potřeba taky poštovné… Proto jsem řikal, že za nějaké čidlo nevypláznu 2 kila jen tak.

Se snímači od DALLAS po 1wire jsem spokojen. Je to levnější a snazší než bastlit něco jiného.

Když jste nakousli ty příznaky. Tak v CodevisionAVR jsem to dělal takhle
(jen příklad)

[code]
/ I/O porty PIN je pro vstup PORT pro vystup
#define topeni PORTB.0
#define led PORTB.5
#define chlazeni PORTC.3
#define svetlo PINA.3

bit malo;
bit hodne;

void main(void){
init();

while(1){
if(malo){
topeni=1;
chlazeni=0;
}

if(hodne){
topeni=0;
chlazeni=1;
}

if(svetlo) led=1;
else led=0;

}[/code]

ty šílenosti jako PORTA&=~(_BV(PA0)); se mě teda vůbec nezamlouvají.
Jde něco jako v codevision i v GCC? Jinak codevision bitové proměnné i přístup na poty kompiluje do asm velice dobře. A paměti nemám nikdy dost. 8kB v atmega8 padlo hned. Naposledy jsem měl dostatek paměti v AT89c52.

Výhoda byla, že jsem měl nahoře vše definované a když jsem přešel na jiný procesor, nebo nevycházela DPS stačilo se šoupnout s pinem jinam. Když to nebyl zrovna nějaký speciální. Včetně LCD Ty 3 piny co na to potřebuji mohli být každý jinde.

Mám rutiny pro alfanumerické LCD po 3vodičích pro CVAVR a jak jsem tak poznal tak přes ty všechny složitosti to asi do GCC jen tak nedostanu
:frowning:

Omlouvám se za příspěvek trochu mimo tok, nedokoukl jsem na datum a nevšiml si že to má ještě jednu stránku.

Když budeš používat všelijaký fičurky překladače místo C syntaxe, tak se ti bude program samozřejmě portovat velice těžko. Ani PORTA&=~(_BV(PA0)); neni ansi C. Když už, tak PORTA&=~(1<<PA0); Tohle je korektní zápis a jde přeložit všude (samozřejmě pokud jsou definovány PORTA a PA0). Samozřejmě lze tuto “šílenost” schovat pod makro :wink:.
Opět “bit” C nezná a ani většina AVR nemá univerzální bitově adresovatelné registry v IO prostoru pro tyto účely (ale třeba tiny2313 má 3).
O efektivitu se bát nemusíš, na manipulaci s 1 pinem jsou samozřejmě využívány instrukce sbi/cbi.

Je výhodné si hardwarově specifické věci schovat do 1 souboru. Při migraci stačí tento upravit a program jede dál.

Kdybys měl problém s přepsáním nějakého příkazu, stačí se ozvat :slight_smile:

Pokud by se někdo nudil a překousnul angličtinu, může se pár minut vzdělávat :slight_smile:
atmel.com/dyn/resources/prod … oc1497.pdf

piityy: moc užitečná věc to pdf co jsi přiložil. Dík.
Nešlo by to dovést k dokonalosti nějakou fintou? Moc o těchto makrech nevím tak nevím.

např. že by se makro #define SETBIT(ADDRESS,BIT) (ADDRESS |= (1<<BIT))
nějak přepsalo aby se volalo například SETBIT(led1)

a to led1 by bylo někde nadefinovaný třeba jako struktura nebo pole obsahující jak adresu tak bit? Ale to už asi jsem moc pohodlný že? :smiley:

Preprocesor zpracovávající makra je poměrně jednoduchej nástroj. Víceméně akorát implementuje funkci najít/nahradit v libovolném editoru. :slight_smile: Při využití struktur se to pak chová obdobně jako ve tvém přikladu, někde jsem to už viděl, ale zase je to dost závislé na překladači.
Pokud to makro nepotřebuješ univerzílní (jako SETBIT(ADDRESS,BIT)), typicky třeba pro práci s periferiemi, je jednodušší si jich vytvořit více samostatných. Častěji používám jednodušší bezparametrická makra.

#define IIC_PORT PORTD
#define IIC_PIN PIND
#define IIC_DDR DDRD
#define IIC_SDA PD3		// INT1
#define IIC_SCL PD2		// INT0
#define SET_IN_IIC_SCL IIC_DDR &= ~ 1<<IIC_SCL)
#define SET_OUT_IIC_SCL IIC_DDR |= 1<<IIC_SCL

#define SET_IN_IIC_SDA IIC_DDR &= ~(1<<IIC_SDA)
#define SET_OUT_IIC_SDA IIC_DDR |= 1<<IIC_SDA

#define CLRBIT_IIC_SDA IIC_PORT &= ~(1<<IIC_SDA)
#define CLRBIT_IIC_SCL IIC_PORT &= ~(1<<IIC_SCL)

#define CHECKBIT_IIC_SDA (IIC_PIN & (1<<IIC_SDA)) // závorky důležité pro využití ve výrazu
#define CHECKBIT_IIC_SCL (IIC_PIN & (1<<IIC_SCL))

Pod 1 makro jde schovat i více operací, pak ale nesmíš zapomenout na středníky za jednotlivými přikazy uvnitř.

#define INT_SCL_MODE_FALL MCUCR |= (1<<ISC01); \
			MCUCR &= ~(1<<ISC00)

Tak makra a bitové proměnné už jsou vyřešeny k mé plné spokojenosti :slight_smile:
Ale je tu mnohem více dalších problémů. Ani se mě už nechce to sem dávat.

tak třeba jsem nepochopil soubor lss. myslel jsem že to je asm výsledek ale je to nějaká divočina. Vypadá to že funkce delay se nevolá ale nějak záhadně se tam vkopírovává a vůbec se mě to nelíbí. Kusy C kódu tam zůstávají asi pro horší orientaci. No nějak mě to nesedlo.
Delay jsem zjednodušil na char. s int to vypadalo ve stejném duchu ale samozřejmě hůř.

Nenašel jsem jak se vkláda do C kódu kusy assembleru. A jak se předávají a vracejí data (datové typy) z /do funkcí ale to bych když tak mohl vypozorovat. Zatím to vidím že si snad koupím plnou verzi codevisionAVR tam to jde tak nějak samo :slight_smile: akorát jsem si myslel že to negeneruje efektivní kód. Ale po zkušenostech s GCC si to nemyslím. Asi to mám všechno nějak špatně nastavené

:frowning:
prvni_lss.txt (7.57 KB)
main.c (1.28 KB)

Rozhodně bych se hned nevrhal do koupě codevision. Byl jsem zhruba před půl rokem před tím samým rozhodnutím na konec jsem zůstal u GCC a i když se taky neustále potýkám se začátečnickýma problémama jako je třeba přerušení, které jsem tedy už vyřešil. Zajdi na www.mikrokontroler.net kde je pěknej tutoriál a nechej si to přeložit googlem. Je to docela čitelný a jsou tam i uvedené příklady dost se tam toho dá pochytit. Potom samozřejmě manuál avr gcc nevím teď přesně stranu ale do googlu dej něco ve smyslu avr lib c nebo savanah.mongu a manuál taky přeložitelnej googlem a docela čitelný navíc je dokumentace přímo adresáři win avr. Doporučuju si ze začátku nekomplikovat život a používat knihovny delay třeba že dělá i větší kod, časem si to upravíš já jsem zatim tu potřebu neměl (jen jsem si změnil delay na cekej) ATMEGA8 ma 8k flash a pak tu skoro stejna Atmega168 16k flash Doporučuju knihu od Burkharta programovaní mc. AVR v C i tam se toho dá hodně najít a potom tady jsou profíci k dispozici taky mi pomohly za což jim děkuji. Jinak AVRfreak a google a google a všehcno je AJ nebo NJ CZ moc nee. Dneska už můžu říct, že jsem s GCC spokojený a je to zadarmo jen prostě víc hledat a studovat. Přeji pevný nervy s AVRkama v C 8)

vidím, že se začínají prolínat dvě témata

docela složitě - viz: AVR a multitasking je tam i odkaz nato jak na to.
A co se týče CV versus GCC - uvažoval jsem taky o přechodu na GCC, ale zjišťuju, že jeho jediné kouzlo proti ostatním je jenom v tom, že je zadarmo - možná bych mluvil jinak kdybych začínal s GCC, ale když porovnám třeba to , že při znalosti CV jsem zcela hladce přešel na MPLAB- (jen je potřeba si zvyknout na jinou strukturu procesoru) - a jak mi to nejde při učení se GCC.

Nemluvě o uživatelském komfortu (poslední verze CVAVR obzvlášť).

Na u-zone je k mání porovnání několika kompilerů: mikrozone.sk/pluginy/forum/f … ic.php?477

přes to přeze všechno bych chtěl GCC umět i když třeba jen ze “sportu” a i proto, že - jak píše Martin mají jiné a důležitější výhody a já nemám důvod mu nevěřit.

A tímto bych se na Martina ( a samozřejmě nejen na něj) obrátil:
Můžeš nám (nerozhodnutým a pochybovačům) ty výhody blíže popsat?

Koukám že v tom nejsem sám… GCC je prostě složitější.
MPLAB má taky C-kompilér?

Já programoval mimo CV ještě v HITEC PIC C-Kompileru v prostředí HI-tide. A hodnotím také velice pozitivně. Všude jsem udělal vše co jsem chtěl jen v GCC narážím hned u začátečnických problémů s blikáním ledky. Asi si knihovnu na alfanumerický display přepíšu z asm do C. Protože ho jinak do GCC s mými zkušenostmi nedostanu. Ale už teď nevím jak v C napsat rotaci charu s příznakem přetečení který chci dát na pin aby to slušně přeložilo. Obdivuji lidi tady, co dokáží v GCC napsat něco slušného. Ani bych se nedivil kdyby to bylo lepší než v těch našich oblíbených “komfortních” překladačů ale zároveň se mě tomu nechce věřit.

Docela mě zaujal multitasking tady na fóru. Jednou jsem si chtěl taky jeden naprogramovat do 8051. Ale většinou si člověk vystačí s dobře napsaným programem a prioritním přerušovacím systémem.

Jinak dodatek: Jak tady řeším tu funkci delay tak mě o to jde jen teoreticky. Protože si myslím že to “zvěrstvo” mi to může udělat s čímkoli jiným nebo to je tak chytrý a když nebudu jen “zbytečně” zdržovat procesor tak to neudělá?

Fredy: Ta funkce je hodně krátká, proto se možná překladač rozhodl pro její kopírování neboť její volání by kód o mnoho nezkrátilo. Jak máš nastaveny optimalizace? kdybys měl O3, tak by to znamenalo rychlost za každou cenu, což vede k tomuto chování i u delších funkcí. Os je vyvážená většinou nejvhodnější varianta.

Vkládání asm do C se nedá jednoduše popsat na pár řádcích, nicméně lib c manualu (to pdfko ve složce nad html manualem winavr) to je.
Když nepotřebuješ pracovat s proměnnými, je to velice jednoduché, když obsluhuješ malé množství, můžeš překladač donutit k jejich umístění do konkrétního registru a potom je to i v asm jednodušší. Registry R2-R15 jsou v GCC využívány poměrně málo.

Piityy: já si to myslel, tak jsem spekuloval s int versus char a tam to zase nabobtnalo zbytečným kopírováním dat tak to asi taky raději nakopíroval celé. Tak jsem ho zkusil donutit tím že funkci zavolám vícekrát aby se to vyplatilo a taky nic :smiley: .
optimalizaci mám Os, zkoušel jsem všechny a ta co to udělala lip zase neudělala optimálně manipulaci s pinem. Holt vše má něco do sebe. Asi s AVR - GCC užiji ještě hodně legrace než to vzdám. Ještě pro zajímavost zkusím disasemblovat v něčem jiném. Ten lss se mě zdá dost nepřehledný, nechce se mě věřit že to je zkutečně tak jak to tam vypadá/ jak to chápu.

lss není pro disassemblig vhodný, je to docela prasečina. Lepší je program pustit v simulátoru a vpravo nahoře je ikonka, která ti kód zobrazí a bude se díky tomu i krokovat v assembleru.
Myslím, že u té tvé funkce ji bude vždy kopírovat, protože je skutečně hodně krátká. To předání parametrů a několikrát push/pop + ret bude možná dokonce delší :slight_smile:. Když tu fukci zvětšíš, určitš ji bude volat dle tvých představ.

Dovolim si v kratkosti reagovat, ale netvrdim, ze ma teraz v rychlosti napadne vsetko, co by bolo zahodno spomenut. Tak sa prosim pytajte, pytajte a pytajte. Netvrdim, ze budem na vsetko vediet odpovedat tak, aby boli odpovede pozitivne uspokojive :slight_smile:

vyhody GCC osobne vidim v nasledovnom (ale nie pre kazdeho teto vyhody musia byt relevantne)

  1. prekladac je oficialne zadarmo bez akychkolvek obmedzeni. GCC pre AVR sa nemusi pouzit nevyhnutne s AVRstudiom, ale napriklad i s Eclipse, alebo s CB. Tato vyhoda sa prejavi tak, ze ak mi niekto nieco externe programuje, nemusim mu hned kupovat prekladac, aby vysledky jeho prace boli pouzitelne. To je velmi velka vyhoda, ak spolupracujem cas od casu z vacsim mnozstvom ludi.

  2. GCC pouziva rovnake zasady ako na AVR, tak aj na ARM7, tak aj na Cortex, tak aj na PC a tak aj na Linuxe. Zdanliva nevyhoda GCC pre AVR - nie taka implementacna zviazanost s platformou ako pri na mieru sitych prekladacoch je mnou vnimana ako vyhoda. Program sa da pisat tak, ze HW platformu staci vhodne zadefinovat prostrednictvom prislusneho headra.

  3. Prekladac poskytuje relativne slusne vysledky pri preklade. Aj podobne porovnania na ARM7 platforme poukazuju na to (v zavislosti od ulohy), ze bud je GCC najlepsi (zriedka) alebo rozdiely voci inym prekladacom nie su horsie ako o cca 25% (vacsinou)

  4. Obrovske mnozstvo kodu dostupneho cez Internet je napisany prave v GCC. Sam som skusal nejaky projekt napisany pod jednym prekladacom (konkretne ICC profesional) prepisat pod iny prekladac a ta namaha jednoducho za to nestoji. Osobne som to vzdal po troch dnoch prace. I tu bolo niekolko krat uvedene, ze prepisat nejaky vysledok pod iny prekladac je jednoducho dost pracne. Nesuvisi to so samotnym C-ckom, ale s rozdielnym nakladanim s periferiami. Toto nie je sucastou definicie cisteho C kodu a ani nema byt preco.

Prirodzene ak chce niekto programovat velmi velmi dlho iba na AVR, nemusi tento fakt vnimat ako vyhodu.

pouzivanie asm v C-ckovom programe. Pani, uprimne naco je to dobre?
Toto je jeden z dovodov, preco uplnemu zaciatocnikovi doporucujem zacat priamov C-cku a vobec sa neobtazovat ASM. Viem, ze mnohi budu so mnou nesuhlasit, ale je to prave preto, ze potom taky programator citi potrebu pouzivat barlicku v podobe ASM v cistom C kode, co prakticky v 99% nie je k nicomu,len to robi zbytocny sum.

Priklad: Niekto tu uvadzal potrebu rotovat bajtom a testovat bit. Vysledok v GCC (ine prekladace to spravia urcite velmi podobne, ak nie
rovnako)

segment kodu zarotuje bajt a na zaklade hodnoty siedmeto bitu nieco spravi

pokus = pokus<<1;
if (pokus & 0x80) {
// …
}

vynatok z prelozeneho asm (-Os, premenne bez volatile)

115:      		pokus = pokus<<1;
+00000092:   0F00        LSL       R16            Logical Shift Left
116:      		if (pokus & 0x80) {
+00000093:   FF07        SBRS      R16,7          Skip if bit in register set
+00000094:   C00B        RJMP      PC+0x000C      Relative jump

...

Viem, ze sa da dany kus kodu naprogramovat o instrukciu kratsie, ale prakticky je to uplne jedno. Procesor sa aj tak bude vacsinou casu skriabat nozickou v nose. Ziaden prekladac neprelozi zdrojovy kod v C so 100% efektivitou, ako by bol napisany velkym odbornikom priamo v ASM. Vysledky su statisticky asi take, ze kod je cca 1.5-2x dlhsi a cca 1.5-2x pomalsi. No a GCC (i podla tu spomenuteho testu) prelozi vysledny kod cca o 20% neefektivnejsie ako ine specializovanejsie prekladace, napriklad tu spomynany CodeVision.

Ina situacia je, ked treba velmi velmi rychlo vykonat nejaky kus kodu. V GCC nie je najmensi problem v ramci projektu spajat C-ckove programy s ASM kodom v samostatnych suboroch. Tieto su uz pisane normalnym sposobom, nie ako inline asm. Velmi pekny popis i s prikladmi je uvedeny v tu uvedenom tutorialy na www.mikrokontroler.net. Inak ten tutorial je uplne skvely i ked je v nemcine, vdaka obrazkom a kusom kodu je dobre zrozumitelny.

Ak mozem poradit, pri uceni sa C-cka pre jednocipy sa snazte nepouzivat vlozeny ASM. Nie je to v 99,99% pripadov vobec potrebne a pri uvodnych projektoch skor na zavadu. Nastudujte si avrlib. Pouzivajte funkcie tu uvedene. Urcite budete zo zaciatku skumat, ako si s tym ktorym zapisom GCC poradi. Tiez som to tak zo zaciatku (6-12 mesiacov) robil. Dnes to obcas zo zvyku spravim tiez, ale GCC ma zatial vzdy uspokojilo a ani v pate ma nenapadlo nieco prepisovat do ASM.

Najhorsie co je, ze zaciatocnici prechadzajuci z ASM (netvrdim, ze vsetci :slight_smile: ) na C-cko zacinaju s blikanim LED (co je chvalihodne a logicke),avsak oneskorenie medzi zmenami stavu LEDky riesia pomocou nejakej obdoby funkcie delay. A tam sa obcas vyskytnu problemy medzi konkretnou realizaciou oneskorenia a ocakavanim programatora v ASM. To ale nie je dolezite, ako sa oneskorenie dosiahne.
Pre pracu s jednocipmi treba volit pre oneskorenie uplne ine pristupy ako nejaku formu delay (i ked tu sa najdu vynimky, napriklad 1-wire komunikacia). A je jedno ci je program napisany v ASM, alebo v C. Pri blikani LEDky sa predsa nema co procesor napr. 1/2 sekundy flakat v nejakej delay slucke a az potom zmenit stav LED. Na take generovanie dlhych casov treba pouzit nejaku casovu zakladnu od casovaca. Procesor ma makat a nie sa flakat :slight_smile:

To sa ale netyka samotneho GCC, ale hociakeho prekladaca C. A uz vobec netvrdim, ze GCC je spasou programatorov (ten inline asm je fakt klada :slight_smile:, ale autori tvrdia, ze to ma pricinu, nastastie ho netreba prakticky pouzivat).
Kazdy, nech si programuje v com mu vyhovuje. K dispozicii je chvala bohu velke mnozstvo prekladacov a kazdy by si mal vybrat to, co mu najviac vyhovuje. Tu som uviedol vyhody, preco prave mne vyhovuje GCC ale to neznamena, ze by som ine sw balickynejakym sposobom zaznaval.

Mam osobnu skusenost s ICC a GCC. Vysledky v ICC Profesional (inak medzi nami vtedy cca 18000,-sk) bolo pre konkretne moje projekty vyrazne pomalsie a dlhsie. Skusil som GCC a bol som velmi spokojny.
CodeVision osobne nepoznam, ale pocul som nan same chvaly. Pre mna CodeVision nesplna body 1), 2) a 4) a preto pouzivam GCC. Pre niekoho mozu byt tieto body irelevantne a moze na CodeVision ocenit ine veci.