Programování uC Microchip v C

Tak potom v h cku musi byt include jeho cecka?

Nemusí, ani “nesmí”. Překladač ví, že .h a .c se stejným jménem patří k sobě. Naopak .h soubor se vkládá do svého .c pokud je potřeba (bývají tam různé definice, které .c soubor potřebuje).

Tak to vysvetlite prekladacu ze to tak ma byt, v Hlavnom*.C musim mat #include “lcd.c” inak to nechodi… v lcd.C zasa #include “lcd.h”, a je aj ina moznost v hlavnom*.C mat lcd.h aj lcd.c

Vtom případě je to blbě napsaný nebo je blbě nastavený IDE (který volá překladač), případně není zdroják přidán v projektu a IDE o něm neví (vloží ho tam až preprocesor).
Že je vložen lcd.h v lcd.c je vpořádku.

a máš to lcd přidané do projektu? v source files

Nie lebo sa to nepaci prekladacu tam je len hlavne cecko, ked to troska upravim dam to sem.

Som spät… prosim navod, lebo tak sa robit neda neviem spojazdnit prerusenie na 16f628A pomocou TMR0.

Urobim take veci: inicalixacia

[code] SETUP_TIMER_0(T0_INTERNAL);
SETUP_TIMER_0(T0_DIV_256);

//hlavna slucka
CLEAR_INTERRUPT(INT_TIMER0);
ENABLE_INTERRUPTS(INT_TIMER0);
ENABLE_INTERRUPTS(GLOBAL);

delay_ms(300);
delay_ms(300);
delay_ms(300);
DISABLE_INTERRUPTS(INT_TIMER0);

//program prerusenia to ani neregistruje prekladac a na adrese 0x4 ma vyse nejaku slucku ci co …proste nechapem prikladam realizaciu prerusenia

void timer0interrupt (void)
{
if(INTERRUPT_ACTIVE(INT_TIMER0)) // Was this a timer overflow?
{
s=~s;
chybakomunikacie=1;
error=0;
CLEAR_INTERRUPT(INT_TIMER0);
}
}

[/code]
TAk ze ak niekto ma funkcnu rutinu pre prelladac PICC tak by som poprosil.

kdyz si otevres help a najdes si #INT_xxxx tak zjistis ze preruseni se pise #int_timer2 //timer0/timer1 void timer2interrupt() { }

ja blbec… ja som otvoril PDF od HItech compilera :blush:

Ahoj, nevím jak toto specifikovat do googlu.
Chci mezi sebu vynásobit 2 int čísla a výsledek by se mi měl uložit do proměnné long. Jenomže kompilátor C30 mi výsledek násobení ukládá jako int a horních 9 bitů výsledku zahodí.

unsigned int U_BAT;
unsigned long UBAT;
U_BAT = 740;

UBAT = U_BAT * 31439;

V MPLABu v okně Watch vidím, že mám UBAT reprezentován jako 32b registr, ale při vynásobení se naplní jen spodních 16b a zbytek se mi nikam neuloží a ztratí se.

Používám dsPIC33FJ16GS502
Děkuji

Možná by mohlo pomoct přetypování:

UBAT = (unsigned long)U_BAT * (unsigned long)31439;

no ,je to logicky , U_BAT je 8bit tak vysledek bude taky max 8bit
UBAT = (U_BAT * 31439); zapis to takle
U_BAT * 31439 -> vysledek se ti ulozi do U_BAT a ten pak do UBAT :bulb:

Panda38: Díky moc, funguje. Přesně jsi pochopil co potřebuju.

MiloPS3: No mě to vůbec logický nepřijde, že když mezi sebou nasobím 2 16b čísla a chci je uložit jako 32b že to uloží opět jen jako 16b.
Protože, to samo dělám se sčítáním, tam to funguje samo a bez problémů.

skouse si to s tema zavorkama ?

to je prave ono, neulozin se ti to do 32b ale nejdriv do 16b(U_BAT) a pak teprve do 32d proto se ti zdejchne nekam ten zbytek…
kdyz zapises U_BAT jako 32b tak to chodi,ze? , takze staci to dat do zavorek a nemusi mit U_BAT jako 32b,

MiloPS3 asi jsem natrvdlý, ale vůbec jsem nepochopil o čem mluvíš. :smiley: Proč by to měly závorky ovlivnit?

Případně by to mělo fungovat i takhle:

UBAT = U_BAT;
UBAT *= 31439;

ne to sem natvrdlej ja :laughing: , takze beru spet , v tomhle pripade to neni ono…

parkrat se my stalo ze si to prekladac prepocital po svym asi nejak takto

U_BAT=U_BAT*31439; UBAT=U_BAT;a pak to prave nevychazelo

Jo, to může být že použije pro výsledek stejný registr.

Překladač to běžně bere tak, že zkontroluje velikosti operandů ve výrazu a podle toho použije typ výpočtu, tj. 16b číslo * 16b číslo násobí 16bitově, výsledek je 16b a ten pak uloží do registru výsledku (např. 32b). Měl by mít alespoň jeden operand rozměr 32b aby použil 32bitové násobení.

Při sčítání dvou 16b může být výsledek velký 17 bitů. Překladač musí zajistit i správné nastavení horního slova výsledku (aby zajistil znaménko), takže použije informace ze stavového registru a tam je nejen signum, ale i příznak carry (resp. overflow), který mu řekne že tam má přidat ještě jeden bít. Sčítání 16 bitů může tedy udělat 32b výsledek bez ztráty dat.

Ahoj, jak se dá v XC16 zjistit skutečná adresa buňky pole v RAM kam ji umístil kompilátor? Nějak k tomu nemůžu dojít.

Chci rozchodit krmení grafického LCD přes SPI PIC24 a data do SPI tam sypat za pomocí DMA z “video RAM pole”. Potřebuju nastavit počáteční a koncové adresy pro zdroj dat. Na LCD bude převážně grafika s výšším FPS.

Děkuji.

A co zkusit tohle :

[code]char Pole[PocetPrvku];
char *AdresaBukny, *AdresaPole;

AdresaBunky = &Pole[KteryPrvekChces];
AdresaPole = Pole;[/code]
případně

AdresaPole = &Pole[0];

To by snad mělo chodit v jakémkoliv Cčku.

Bývalo dobrým zvykem, že kompilátory generovaly LST soubor (listing - nemusí mít vždy příponu .lst), kde byly všechny adresy a symboly shrnuty - XC16 už to neumí?

Edit: Takže si odpovím sám - XC16 User’s Guide praví: