Декларирай А и В като static int.

подкарвал съм ги и на 200 меги...има си и ерати, ама няма вечно щастие
по принцип си направи някъв дебъг fprintf() към конзола

Не че съм някакъв гуру в програмирането, напротив- уча се в момента, ама и аз съм съгласен с мнението, че така написан кода е безсмислен. Не съм пробвал на PIC32, но този код на PIС18 оптимизатора маркира result като неизползваема променлива и я игнорира (т.е. няма код за нея).

Wizard, един въпрос! Защо когато поставя main.c в папка(т. е. не е root директорията на проекта, а в ~/papka), XC32 няма връзка с основните си библиотеки? Не може да намери къде са xc.h, string.h, stdlib.h и т. н. Когато го върно в root-а, всичко е наред и другите файлове дава да са в папки. Явно е някакъв каприз пак. Инклуднал съм тези папки, които съсдавам в проекта! Някаква настройка да не да съм "опущил"?!
Благодаря!
ПП: Не местя просто файла! Всеки път си пиша #include <xc.h>, за да го свържа правилно с библиотеката... При XC8 и XC16 няма такъв проблем.

stoyanoff, това животно няма ли лог?
Ако покажеш лога ще е много по-ясно какъв е проблемът. Без да се обиждаш ама термините ти са много объркани.
1) Има библеотеки има и хедър (*.h) файлове. Има и разлика между двете.
2) "връзка с библиотека" или "свързване" или "линкване" се нарича процесът след компилация и той се извършва от линкера. Хедърите нямат връзка с тоя процес. Те се "инклудват" или "вмъкват" по време на препроцесинга, демек преди компилация.
При GNU/GCC тези процеси се правят с различни тулове, CPP за препроцесинг, GCC за компилация, LD за линкване. Съответно има опции за указване на пътища. За хедър файлове се ползва -I, за библиотеки се ползва -L но за стандартните библиотеки обикновено няма нужда да указваш каквито и да е било пътища.
3) Общо всички процеси обикновено се управляват от МАКЕ и от мейкфайл, който може би в твоя случай се генерира. Въпросът е че при сложен проект някои идиоти го цепят на части и вместо един общ мейк пускат рекурсивно мейк за отделните части. Споменавам това, понеже ако имаш рекурсивен мейк със смяна на текущата директория това може да се отрази на пътищитата (ако ползваш релативни пътища за хедъри/библиотеки)

Изобщо не стигам до компилация! Да опитам да обясня пак:
Правя си проект. Създавам си нов main.c, като го поставям в директорията на проекта! Всичко работи - без проблем си инклудвам всякакви стандартни хедър-и - xc.h, string.h, бла бла бла. При това положение всичко е 6.
Правян нов проект. Вътре в проекта създавам папка - пр. project files. Инклудвам тази директори в gcc opitimization раздела и си правя main.c като го поставя във въпросната папка project files. Този път обаче, когато опитам да напиша #include <xc.h>, компилаторът ми казва, че не може да намери въпросния файл. И за всички стандартни хедър-и е така. Все едно няма връзка с папките с тези файлове в директорията на самия компилатор. Аз им казвам библиотека. Както решите, така ги наричайте. Не говорим за компилация! Когато извадя main.c от project files, всичко е 6. Имаме връзка, а вътре в папката мога да си слагам други файлове, за които вече не прави проблем с откриването на хедър-ите. Както отбелязах, при XC8 и XC16 такъв проблем няма! Или има някаква настройка, за която не знам, или е някаква бъгава работа като предната...
ПП:Миро, какъв лог да ти покажа?!

Интересното е, че дава, че търси в директорията на компилатора! Обаче защо не го намира....

нямам си на идея що - хем вижда хем не вижда <std>, неправилна инсталация...
tools->options->embedded виж кви са пътищата
незнам - ресетни му настройките за проекта или го преинсталирай
не ми се е случвало тва... последното, което преживях е да липсва код и да си мълчи - ни варнинг ни еррор ресетнах настройките на С, линкер минкер и ми докладва - абе тук не намирал еди кво си.......

амa ако търсиш периферия(PLIB) за 32 - няма библиотеки - не били готови за последните версии

Пробвай все пак да го компилираш това. При мен на моменти така си свети почти всичко дефинирано в стандартните .h, но се компилира нормално. Оказа се, че е проблем на средата, не на компилатора. Лекувам го с чистене на кеша.
Ето тук го бях прочел.
https://stackoverflow.com/questions/14913243/netbeans-7-2-shows-unable-to-resolve-identifier-although-build-is-successful

+1, това е анализатора на IDE-то и е често срещано заболяване, особено в комбинация с GCC. Проблемът е, че GCC не е много удобен за код анализ и затова средите ползват други средства, съответно често има разминавания и проблеми.

Когато е прост проекта, компилацията минава. Когато обаче заредя нещо сложно, започват глупостите - вади ми, че даден регистър не съществува и т. н. Това мога да го преживея.
Обаче нещо имам проблем с UART-a. Данните се изпращат правилно и съответо, отсрещната стана отговаря(това го виждам на анализатора). Обаче дебъдер-а увисва. Като дам на пауза не сочи къде е! Данните са приети в буфера и до там. Добавих в прекъсването проверка за грешки - PERR, FERR, OERR. Засякох OERR грешка, но не съм сигурен дали я изчиствам правилно. В документацията пише, че когато се изчисти софтуерно, трябва да се изпразни входния буфер и да се рестне SRS. Обаче този контролер, като че ли няма SRS(PIC32MX150F128B). Аз поне не намирам регистър, в който да сетна shodow-a. И при прекъсването не ми дава да използвам IPL7SRS(като не съм го сетнал...) и за това използвам AUTO. Не знам дали е правилно. Предполагам, че нещо съм омотал тук.
Ето го прекъсването:

Може ли малко разясненя тук?
Благодаря!

А включил ли си мултилевел интъръпт...пиша от телефона... периферията на 32ката е същата като на 16 битовите с + екстри
Фифо буфера се чисти като се чете докато се изпразн

забравих че в раницата имам лаптоп:
общо взето тряя да де оправиш... разкарал съм RTOSките неща
кепчъра за еррор е за уарт 2 но принципа е същия

//FROM INIT
static inline __attribute__((always_inline)) void HardwareUseMultiVectoredInterrupts( void )
{
__builtin_disable_interrupts();
/* Enable multi-vector interrupts. */
_CP0_BIS_CAUSE( 0x00800000U );
INTCONSET = _INTCON_MVEC_MASK;
__builtin_enable_interrupts();
}


void DBG_Init(uint32_t brg) {
SystemUnlock();
//REMAP PINS
RPD15R = 1;
U1RXR = 3;
SystemLock();

U1MODE = U1STA = 0;
U1BRG = (unsigned short) (((float) SYS_CLK_BUS_PERIPHERAL_1 / (4.0 * brg))-(float) 0.5);
U1STASET = _U1STA_UTXEN_MASK | _U1STA_URXEN_MASK;
U1MODESET = _U1MODE_ON_MASK | _U1MODE_BRGH_MASK;

// ENABLE RX INTERRUPT
/* set rx interrupt priority */
memset(&dbg, 0, sizeof (struct _DbgContext));
IPC28CLR = _IPC28_U1RXIP_MASK;
IPC28SET = (2 << _IPC28_U1RXIP_POSITION);
IPC28CLR = _IPC28_U1RXIS_MASK;
IPC28SET = (0 << _IPC28_U1RXIS_POSITION);
IFS3CLR = _IFS3_U1RXIF_MASK;
IEC3SET = _IEC3_U1RXIE_MASK;
//TRACE_INFO("UART ENABLED\n");
}


/* INTERRUPT RX */
void dbgReceive(void) {
static int c;
while (U1STA & _U1STA_URXDA_MASK) // READ FIFO
{
c = U1RXREG;
//SAVE C
}
IFS3CLR = _IFS3_U1RXIF_MASK; // CLEAR RX IF
}

void uHandlerError(void) // FROM ISR OR...
{
static int c;
U2STACLR = _U2STA_OERR_MASK;
while (U2STA & _U2STA_URXDA_MASK) c = U2RXREG;
IFS4CLR = _IFS4_U2RXIF_MASK;
IFS4CLR = _IFS4_U2EIF_MASK;
}

ASM FILE:

#include <xc.h>
//#include "ISR_Support.h"

/* USART1 Interrupt */

.extern dbgReceive
.section .vector_113, code, keep
.equ __vector_dispatch_113, IntVectorUsart1_Receive
.global __vector_dispatch_113
.set nomicromips
.set noreorder
.set nomips16
.set noat
.ent IntVectorUsart1_Receive
IntVectorUsart1_Receive:
la s6, dbgReceive
jalr s6
nop
.end IntVectorUsart1_Receive


/*******************************************************************************
End of File
*/

Въпрос! Къде мога да намеря списък с тези маски? До колкото разбрах, е добре да използвам CLR регистрите и маски вместо да пиша директно в регистъра. Всъщност схващам долу горе как се формира label-a, но някои неща не са чак толкова по подразбиране. Примерно това за отключването не ми го разпознава. И за soft рестарт намерих само едно abort() примерно...
Това, което аз видях като запис от документацията, е:

Това вече deprecated ли е?
Благодаря!

void __ISR не е deprecated
просто копирах от мои сорсове, ползвам ги с RTOS, но разкарах макросите switchConetext
маските са в <xc.h>
CTRC-Click на регистър или маска

Bitfield операциите на са атомик в 32-ките, а за интеръпт изобщо не са за предпочитане
по-принцип може да ги ползваш

abort() е стандартна функция на C и се очаква потребителя да предостави такава - поне около gcc-то. Същата се вика и ако има assert който не мине.