ПРОБЛЕМ и РЕШЕНИЕ на компилирания код за ПИК ПРОЦЕСОРИТЕ със XC8 компилатора, версия v2.64
графика на засечения ХЕКС / HEX / код качен във флаша на пик процесора PIC18F27/47/57K42. разположението на хекс байтовете започва от средата на флаш паметта и се разпространява към двата края на адресите според големината на сорс кода от проекта
0х10000 >>> 0х00000
0х10000 >>> 0х1FFFF
Това води до невъзможност на девелоперите да използват свободната флаш памет за четене / запис директно вътре в процесора за данни, които са необходими директно в хардуерно / софтуерни проекти / решения. за пример можем да вземем, че тези свободни зони от флаш паметта могат да бъдат използвани като по-голям ЕЕПРОМ директно във флаш паметта на пик процесора, като за четенето и записа във флаш паметта има налични софтуерни функции дадени от микрочип в код генератора.
Графиката по долу добре показва разположението на хекс байтовете от компилирания код, който е качен от програматор и / или от функцията за запис на флаша в буутлодера.
дадените адреси, където трябва да се запишат хекс байтовете са дадени във компилирания хекс файл, който е по ИНТЕЛ ХЕКС СТАНДАРТ / INTEL HEX STANDARD /, така че реално в записа на данните прогрматорите и буут лоадерите нямат отношение към пресмятането на адресите къде да бъде записан и как да бъде разположен хекс файла във флаш паметта.
Програматорите и буутлоадер функциите просто декодират данните от редовете на хекс файловете, като във всеки един ред на хекс файла е описано на кой адрес във флаш паметта колко и кои байтове да се запишат.
Адресната аритметика и изчисление / определяне на адресите на хекс байтовете е свързана със архитектурата на процеосора, като с това се съобразява както компилатора, така и линкер програмата за компилиране и правилно пресмятане на адресните клетки във флаш паметта.
Компилирания хекс файл, който може да бъде разчетен / декодиран от всеки запознат със ИНТЕЛ ХЕКС СТАНДАРТА за компилиране съдържа информация както за компилирания сорс код къде да бъде разположен, така и за еепром данните, който също могат да бъдат зададени със макрос във сорск кода директно, тъй като знаете, че еепром паметта може да съдържа важни данни за първоначално зареждане на променливи и/или константи при стартирането на процесора.
Компилирания хекс файл се различава във вариант на разположение на хекс кода в адресите, когато има наличие на буут лоадер зона в стартовите адреси на флаш паметта, както и когато има налични дефинирани прекъсвания от главната функция за прекъсвания, както и описание на функциите обработващ тези прекъсвания във главната функция за прекъсвания в сорс кода.
функциите за прекъсвания в пик процесорите могат да бъдат както една обща за всички прекъсвания в процесора, така и разделени на функции за прекъсвания с нисък приоритет и функции за прекъсвния с висок приоритет, в зависимост от модела процесор, който използвате във вашият проект. също така някой по-големите пик процесори фамилия 18Fxxxxx могат да имат отделен вектор / адрес за всяко отделно хардуерно прекъсване, като това е описано във таблицата на векторите за прекъсване във пдф файла на процесора.
така, за по-запознатите в програмрането / електрониката / автоматизацията тази графика по-долу ще им разясни много повече от хиляда обяснения. за останалите, които искат да научат повече за ИНТЕЛ ХЕКС СТАНДАРТА за компилиране на сорс код на езика С/С++ има го обяснен в нета, аз съм го разкостил целия хекс адре по адрес и знам ко пише вътре и кое къде ще бъде поставено при запис в флаш паметта на пик процесорите.
този проблем има решение, което беше дадено от съпорта на микрочип, след като два месеца им обяснявах какъв е проблема и как трябва да се направи адресната аритметика на компилираните хекс адреси директно във процеса на компилиране на сорс кода от който и да е проект за който и да е пик процесор.
след като съпорта и програмистите на компилатора и линкера във ХС8 разбраха какъв е проблема и какво пречи да бъде направено във програмирането и девелопинга с пик процесорите, дадоха една опция в командата за компилиране, която помогна да се реши този проблем, без да пречи на правилната работа на пик процесорите в каквито и да са проекти, сорс код и други опции в нормалната работа на девелоперите. :) за това ще поговорим следващата статия.
