Колега slav4o.com, намери малко време да прочетеш как става компилацията и свързването на дадена програма.

Когато описваш TestFunc(); в заглавния файл обясняваш, че има такава функция с такива параметри. Тялото на функцията ти е в друг файл, който не е в проекта, т.е. не се компилира/свързва към проекта. Логично ликнкерът, когато търси да сглоби изходния файл да ревне, че такова животно няма.

Сакън само инженерите се занимават с такива глупости - да четат. Истинските, разбирачи, ръгат там к'вот падне, докато се получи нещо. Практика му викат

В стандарта за C, още от ANSI C, има "стандартни" функции, които са задължителни и трябва да са направени от писачите/портировачите на компилатора. За ембедед най-често се ползва newlib проекта, който е стандартна C библиотека, но по-лека и по-гъвкава предвид спецификата на микроконтролерите.
В хедъра stdio.h са описани точно такива функции/символи, които са "вградени" в стандартните библиотеки на компилатора. Има флагове към линкера, с които да изключиш тези библиотеки - това се ползва когато искаш да сложиш твоя имплементация на стандартни функции (например твой принтф), макар че има и други по-лесни начини.
Та твоите библиотеки ще можеш да ги викаш така само ако успееш да убедиш комитета дето движи стандарта да ги вземат и сложат в следващата версия на стандарта ... Ама ти не търсиш чак това, ти искаш сигурно да си билднеш един път някакъв код до статична библиотека (*.a, макар че и с *.o файл е същото) и после да не ти се налага да добавяш сорса в новите проекти. За да стане това все пак ще трябва да инструктираш линкера да ползва тези *.a или *.o предкомпилирани файлове. Това става с аргументи при викането на линкера, т.е. настройки на проекта. Ако е просто *.o файл го слагаш като пореден обект за линкване, ако е библиотека се ползва "-lmylib" което значи "търси файл дето се казва "libmylib.a" (префикс "lib" и суфикс ".а" си слага сам линкера).
За по-лесно разбиране/четене не тормози гугльо с code::blocks като ключови думи - търси просто как се прави нещото в gcc. IDE-то си има в настройките полета, които подава на командния ред на гцц, така че не е лошо да знаеш какво иска гцц, за да угодиш на гуи-то на IDE-то (знам, звучи странно, но в ГУИ-тата това е често срещано затруднение - затова Еклипса има едно поленце, дето ти показва какво аджеба ще подаде с накълваните от теб чавки и текстове по ГУИ-то).
Та просто провери за "gcc linking static library", "gcc create static library" и такива търсения.
Това за какъв контролер и какво IDE го бориш? Май за XC8 се говореше, и код::блокс? Това ако го правиш с идеята да учиш C е малко извратено - сещам се само за 8051 като по-гаден вариант. Какво толкова не му харесваш на еклипса примерно? Информация кое как се прави там е в порядъци повече, да не говорим че е доста по-качествен редактор (е, C::B от 10-тина години не съм пипал, да не се окаже че е задминал еклипса?)

edit: не му е тука мястото, но причината да се пред-компилират библиотеки е че липсва доверие в билд системата (make, ...) че тя сама ще успее да оптимизира процеса и тоя твой testfunc.c ще се билдне еднократно до подходящия testfunc.o и после няма да се губи време. И че ако пипнеш нещо, което би повлияло и би изискало ребилдване на testfunc.c то наистина ще се случи. Когато това доверие липсва (често съвсем основателно заради бъгове и недостатъци на билд системата) хората масово прилагат за всеки два нови реда "save file -> save all -> clean all -> rebuild all -> rebuild ...", че някога и ходят ръчно да трият билд папки за да са сигурни че нещо не е останало. Това води до усложнението че всеки билд / промяна отнема време, което при по-големи проекти може да е проблем. Пред-компилирани библиотеки и хедъри спестяват това време, като разделят процеса на отделни зони. Но това го прави програмиста ръчно - "ами това ще го направя библиотека, ами сега я билднах и няма да я пипам повече, другото го билдвам отделно и понеже съм умен знам че не съм пипал в библиотеката и няма да я чакам".
Това води първо до допълнително работа за да го направиш като проект (самите сорсове сигурно вече си ги отделил в папки/файлове, но това не стига, иска и проект да му направиш за да го пред-компилираш). Второ, изисква да следиш че библиотеката ти е актуална и синхронизирана с нейните сорсове. И това се автоматизира, разбира се, но пак е ръчна работа, която основно гони спестяване на билд време.
Алтернативата на тоя подход "разделяй и владей" е билд системата да е достатъчно способна и надеждна във вършенето на тази работа. Има няколко съвременни такива системи, които все още проучвам, но за справка ще спомена:
- tup: http://gittup.org/tup/ - има си документ с теоретичната постановка на проблема: http://gittup.org/tup/build_system_rules_and_algorithms.pdf
- conan.io - това го водят package manager за C/C++ - много интересна дивотия е, целта е като си направиш нов проект да кажеш "искам boost, искам libssl, искам ..." и да ти направи проект, в който да пишеш - не търсиш хедъри, не компилираш за твоя специфичен таргет; ако му е позната boost за твоят платформа, например от предишния проект, ще вземе наготово библиотеките от локално репозитори, ако ли не ще дръпне сорсовете, ще ги конфигурира и ще ги билдне с твоя тулчейн
Като цяло tup-а е впечатляващ инструмент - феноменално бърз е, намира си допълнителни зависимости сам - например пускаш билд на testfunc.c и той се билдва, понеже ползва хедъри от текущата папка, например testfunc.h. В командата към gcc ти хедъри не си подавал, т.е. в "мейк файла" да го наречем не си има споменаване на testfunc.h. Съответно make ако беше нямаше да знае за testfunc.h и ако смениш нещо може да не получиш очаквания резултат.
Тоя диват tup следи командния ред, но и се закача да дебне процеса на gcc какво ще докосне - ако gcc отвори файла testfunc.h значи този файл е важен за билда, и tup си го маркира в неговите описания на проекта автоматично. Така си изгражда граф на зависимостите и не изпуска нещата от контрол. Ако смениш gcc екзето ще те хване и пак ще ребилдне всичко, което знае че е пускал с предишното, за да актуализира обектите и другите артифакти.
За да са още по-бързи има и мониторинг на файловата система - след като знае че testfunc.c и testfunc.h са важни оня се закача към OS-а да бъде информиран ако някой модифицира тоя файл. Ти пишеш два реда, записваш и в тоя момент онзи знае за промяната и си опреснява вътрешните графове кои неща да компилира при следващия билд (ако тоя хедър се инклудва в няколко файла ще знае че трябва да ребилдне няколко файла, ако те се линкват в 20 други места ще знае и за това).
По този начин инкременталните (частични) билдове са мигновени и не се стига до нуждата от пълен, чист билд освен първото билдване.
На тази база са направили линукс дистрибуция, пакетите в която се билдват по този начин: http://gittup.org/gittup/
Всъщност инструмента tup не е само за компилиране - той е много по-общ, също както и make. Прави връзка от типа зависимост между два файла - в случая с компилатора е между *.c и *.o, но може да е произволно нещо. Не е фиксиран да вика gcc (както и при make), може да вика произволен инструмент от командния ред - разни код-генератори примерно, но и много други цели.

C::B си е окей за ПЦ, особено ако правиш леки неща. Мисля- Славчо си пуска XC8 в случая само за сравнение.
Едва ли си е наумил да пуска ПИК през C::B.
Веднъж коментирахме ,че Еклипс/Джава иска мощен процесор, иначе е тегаво.

Това кога сте го коментирали - преди 10 години или повече? Не изключвам вероятността някой да се опитва да го пуска на 2G RAM, но е несериозно да се твърди че е тежък. Netbeans-а (mplab-x) е не по-лек и пак е джава. Само че на еднакви pc-та мплаб-х-а е далеч по-бавен от еклипс. За 89лв си взех малко PC с 4Г рам, двуядрен интел на 3Гхз с 6МБ кеш - колко да е трудно човек да си вземе нормално PC ако ще работи в тая сфера?
Последните visual studio версии (2017, 2019) са много по-тежки и бавни. Вярно че dev-cpp или code::blocks са много по-леки, но това е за сметка на функционалност. А visual studio-то си е тежко и без да предлага нещо повече като екстри.
Както и да е, може би не е тук мястото да го коментираме това - макар че колегата май точно сега започва и би му било от полза да се насочи към по-качествена среда, в смисъл с повече възможности - да кажем codan на еклипс помага много с моменталното осветяване на грешки докато редактираш, преди още да си билднал или да си минал на друг ред/файл. Това е много ценно за начинаещи.
А пък изобщо говорим как да подходи за ученето бих препоръчал да си сложи един линуск, ако ще е като dual boot или виртуалка и там да се хване с ученето. Самото "стоене" на виндоус води към грешни навици - трябва да има инсталатор, за да го сложа, трябва всичко да е накуп. Под линукс ще види кое откъде идва и защо е отделено, как се работи и т.н. По-близо е до първоизточниците. То и под вин може, но дев-цпп имаше някакви плъгини мисля - еди коя си библиотека, с примерните и т.н. Не че е лошо, това си беше package manager, но много специфичен.
Аз от няколко години се преобърнах и не съжалявам - дори и не осъзнавах че при съвременно ssd и много памет/кеш може един изтеглен от интернет архив няколко стотин мб да се разархивира за секунда-две, стига да няма отзад няколко дебнещи да го огледат процеси - антивирус, телеметрия, ускорение на търсенето, и това от двете страни - първо архива докато се чете от диска преди да се разархивира, после отделните файлове докато се пращат към диска . И за всичко това си плащам - за ОС, за антивирус, за бързи ssd-та, за як процесор, за много РАМ - сега 16Г не мога да ги напълня колкото и дивотии да вървят отзаде - билд сървъри (на джава), сорс код платформа (bitbucker), няколко докера за дреболии (всъщност забравени след като съм ги пуснал). И swap не ми трябва, ама съм сложил да има. Под виндоус ако оставя pc-то повече от 2-3 дни без изключване и ми напълва рам-та и почва да swap-и - та ме кара да рестартирам периодично и пак да го чакам дивака.

Ти си много напред с материала и малко трудно ти разбирам .
На мен Уиндоуса ми е достатъчен, купувам за работа стари лаптопи, разхождам ги по полето, и досега повече от И5 съм нямал , а и не ми трябва.
На тоя И5 MPLAB xc8 стои добре, сигурно и еклипса ще върви добре, но засега не ми трябва.
Визуал Студио съм инсталирал няколко пъти ..за много кратко, ВинАпито ми е достатъчно в КодеБлок, за прости задачи по серийния кабел.
Та всяка гара си има пътници, като влаковете.

Че какво му е на i5? Напълно достатъчно е.
Съвсем сериозно, ако имаш време и желание сложи един еклипс за c/c++, направи си проект с визардите и разцъкай малко. После си реши дали да го махнеш или не. Загубеното време все си е опит някакъв.

Инсталирах последния еклипс 2019-12 с последната джава JDK 13 . Тръгна. Има пробен Hello World ! на C++ ама нещо не тръгва:

или

бавно си върви, по-бавно от MPLABX 5.30
но това е заради бавната джава

Е той gicho те метна в дълбокото... еклипса въобще не е толкова лесен за подкарване, особенно в часта си с хардуерения debug

В това отношене MPLAB, IAR и прочие са "отваряш кутията и работи". Eclips-a си иска бая псуване....

Не е лошо човек да овладее и "примитивни" инструмени като:

• работа в конзола без ГУИ
• прост текстов редактор
• Make(file), grep и т.н.
• gcc, clang или какъвто там е виндовския аналог от visual studio
• gdb, jtag, openocd и т.н.

Защото:

• Повечето IDE-та са всъщност обвивки които отдолу ползват точно тези интрументи и познаването им понякога може да спести много главоболия
• Тези инструменти ги има инсталирани и конфигурирани на повечето дев машини и с тях човек може да се оправи набързо на момента без да му се налага да инсталира няколко часа нова машина за да свърши работа за 5 минути
• Така може да се дебъгва или в някои случаи даже се работи (фиксва грешка в сорса, компилира и т.н.) направо на крайното устройства (разните му ARM dev boards примерно с по 1-2 гигабайта рам)
• Да се работи на отдалечена машина - ако не си си в офиса или пък трябва да оправиш нещо на другия край на България или света и т.н.

Едит:

Общо взето идеята е, че най добра ефективност се постига с добри умения и добри инструменти, обаче когато ги няма и двете е по добре човек да има уменията отколкото да не умее да ползва инструментите.

Славчо, "Глобални променливи в С" се казваше темата.
Каквато и среда да инсталираш- променливите са все глобални и локални .
Тукашните гурута могат да те посъветват , ако опишеш целите си, работния си компютър и бюджет.
Не си губи работи времето с търсене и инсталиране, чети Ц-то , а за средата - виж по-горе.

И да знаеш, че между 13ч на 31 декември и 14 часа на 1 януари - никой компилатор не работи добре.
Весела Нова Година !

@palavarov, тия инструменти дето ги изброи, са толкоз "примитивни", че 90% от програмистите не са и чували за тях. Много на дълбоко го мятате...

Да овладееш make системата е по-сложно, от колкото да пропишеш на С, бре! Човека се мъчи да качи Витоша, вие го засилихте космонавт да става...

Какво IDE ще ползва, е обект на това каква задача ще решава. И с MPLAB можеш да напишеш добре работещо приложение и с цял чувал GNU инструменти можеш да натвориш говна... Даже второто е по-вероятно, щото вместо да се съсредоточиш върху забиването на пирона, се мъчиш с изработката на чук

Туй ще да е по виндовс? Трябва ти компилатор - виндоуса сам си е виновен че идва без компилатор. Не че всички линукс дистрибуции идват с такъв, но повече да.
Сложи си (ако все още искаш да се бориш) mingw компилатор и би трябвало да работи за под виндовс.
Иначе за хардуерен дебъг на ембедед системи не е толкова лесно, но по-скоро зависи колко са се постарали от фирмата, дето прави хардуера. Например при TI нещата са пределно лесни, при други е мъка - щото вендор-а си и чесал....

Edit: това е един от инсталаторите за mingw: http://mingw-w64.org/doku.php

MinGW инсталиран си има покрай КодеБлокс,
само трябва да го свърже с Еклипса, ако е възможно.

и за кво са ти Еклипс, MinGW ... кат ще пишеш за Windows - Visual Studio ... може и стара версия