| Микроконтролери и електроника http://mcu-bg.com/mcu_site/ |
|
| CBS setup http://mcu-bg.com/mcu_site/viewtopic.php?f=7&t=9305 |
Страница 1 от 1 |
| Автор: | RM [ Пон Авг 29, 2011 9:55 pm ] | |||||||||
| Заглавие: | CBS setup | |||||||||
http://mbed.org/users/igorsk/programs/DriverLibrary/601ro/docs/lpc17xx__uart_8c_source.html
Нещо не мога да вържа драйверите към вектора на прекъсване, Когато се опитвам да ползвам подонби драйвери, при влизане в прекъсване , вектора на прекъсването ме праща в някакъв безкраен цикъл даден по умолчание ... Как става в това ГЦЦ. |
||||||||||
| Автор: | miro_atc [ Пон Авг 29, 2011 10:17 pm ] | |||||||||
| Заглавие: | Re: CBS setup | |||||||||
Тоя цикъл да не би случайно да е fault exception ? Като викаш функция при ARM най-младшия бит указва дали да се смени режима (thumb/arm).... от тук и "указател към функция" е малко подвеждащ. Ако го ползваш като адрес за данни (както ти май го присвояваш към void*) се взема началния адрес на функцията.... И след това като го кастнеш до указател към функция компилатора няма откъде да знае каква е била функцията (arm или thumb). Всъщност разчита че му подаваш адрес + mode. С две думи или не лъжи GCC с тайпкастове и не му крий типовете... или след като си го излъгал му добавяй 1 за thumb функции... |
||||||||||
| Автор: | RM [ Вто Авг 30, 2011 1:03 pm ] |
| Заглавие: | Re: CBS setup |
Това е драйвер за LPC17xx УАРТ.0.1.2. Предоставен е свободно от NXP. До сега не съм го ползвал, по право почти не съм ползвал такива процесори, освен I2C с полиране на трансфера без прекъсване. Сега ми трябва една температура един ОУ с управляемо усилване, и то на и2с. Температурния датчик ще ми дава температура минимум през 100мс, и ще ми трябват прекъсванията на и2ц, или не мога да измисля трансвер с полиране към повече от 1 слейф без да замотам нещата. В стартъп фаила имам #pragma weak UART_IRQHandler = Default_Handler след това static void Default_Handler(void) { /* Go into an infinite loop. */ while (1) { } } Да .... и сега функцията за обработка на прекъсванията на УАРТ са ми в съвсем друг файл lpc17xx_uart.c Ако направя така: В началото на стартъп фаила extern void UART_GenIntHandler (void); // въпреки че функцията има атрибути, може ли да е void и след това... #pragma weak UART_IRQHandler = UART_GenIntHandler Как да вържа вектора UART_IRQHandler с обработката на прекъсванията UART_GenIntHandler във външен файл |
|
| Автор: | miro_atc [ Вто Авг 30, 2011 1:59 pm ] |
| Заглавие: | Re: CBS setup |
досега не съм се занимавал с LPC а да почна аз едва ли ще ползвам техен код. Така че не мога а и не искам да вниквам какво правят те и какво правиш ти... Това, което мога да помогна е принципни въпроси свързани с АРМ архитектурата и GCC. Единия проблем ти го казах с указателите към функции и тайпкастовете. А другото нещо е WEAK атрибута - той може да се слага към произволен ликерски символ (функиция, глобална променлива и т.н.) Няма отношение към типа на нещото. Има отношение към линкването (свързването). Нормално при линкване ако се появят две дефиниции на нещо от един и същ тип се получава грешка. Но ако едно от нещата е WEAK няма да има грешка, то ще се игнорира и вместо него ще линкне и ползва другото нещо. Идеята е не само да няма грешки, чрез WEAK може да се портва чужд код, без да се налага да пипаш из чуждите сорсове. Примерно (не знам дали е така при теб) може да имаш готов стартъп файл, в който има някакъв хендлър на UART. Може да го използваш тоя код така както си е и по подразбиране ще се ползва тоя хендлър в него. Но ако не те кефи и ако тоя хендлър е с WEAK атрибут ти може някъде другаде в твоя проект да направиш функция със същото име и тип, но без weak. При линкване ще се ползва твоята функция, а wеак-функциията ще изчезне. Забележи, че така може да подменяш функции, без да пипаш чуждите сорс файлове. Така ако утре излезе нова версия на чуждия файл - само си го копираш, без да се притесняваш че ще изгубиш твоите редакции... |
|
| Автор: | RM [ Вто Авг 30, 2011 2:42 pm ] |
| Заглавие: | Re: CBS setup |
С клизма ... проблема замазах така. extern void UART_StdIntHandler(void); //Указах му че има външна #pragma weak UART_IRQHandler = UART_Handler в същия файл с нова функция викам extern-а която ми трябва static void UART_Handler(void) { void UART_StdIntHandler(void); } |
|
| Автор: | miro_atc [ Вто Авг 30, 2011 4:17 pm ] | |||||||||
| Заглавие: | Re: CBS setup | |||||||||
верно правиш дивотии Значи в стартъп файла ти предполагам имаш векторна таблица, в която за uart-a вектора е UART_IRQHandler Тъй като не се знае дали тоя стартъп код ще се ползва с uart или без, хората са ти сложили:
Тая прагма създава weak символ UART_IRQHandler който сочи към Default_Handler, така стартъп файла ще може да се компилира при всякакви обстоятелства. Има си вектор, има си и хендлът (дефаулта).... От тук нататък най-логичното е ти да сложиш още сорс файл в който да има нормален/истински UART_IRQHandler без атрибути и без прагми. При свързване линкера ще види че имаш един нормален символ UART_IRQHandler и един weak. И навсякъде ще замести с нормалния. Ти обаче правиш втори weak UART_IRQHandler, който сочи към UART_Handler..... Що?? Искаш да объркаш линкера и да се чуди кой от двата weak-а да ползва? |
||||||||||
| Автор: | RM [ Пет Сеп 02, 2011 10:53 pm ] |
| Заглавие: | Re: CBS setup |
Малко бях зает но успях да си направя, комуникацията. miro_atc , благодаря ти много. Не знам но ми харесват тези драйвери, притеснителното за мен е че са написани много професионално и трябваше да седна да разгледам много добре кода. Не е като CVAVR , CCS или микроелектроника. |
|
| Автор: | RM [ Съб Сеп 03, 2011 1:49 pm ] |
| Заглавие: | Re: CBS setup |
| Автор: | miro_atc [ Съб Сеп 03, 2011 5:24 pm ] |
| Заглавие: | Re: CBS setup |
ммм... не съм убеден, че разбирам какво се опитваш да направиш По принцип имаш препроцесор (CPP), компилатор (GCC) и линкер (LD). Това са три различни неща, всяко работи с различни понятия и си имат различни опции, макар че може да работиш само с GCC и да го накараш то индиректно да извиква останалите. В последния случай опциите наистина са на едно място, но въпреки всичко е добре да знаеш коя опция за кого де отнася. Сега опции за дефиниране на array не знам да има. Не че знам всичко де, но мисля че няма такова животно Има опция (-D) с която може да дефинираш символ - просто символ. Това е опция на препроцесора, т.е. може да имаш #ifdef примерно с тоя символ. Но пак подчертавам, че това няма връзка с типове и масиви на компилатора. Идеята на препроцесорните символи е по-скоро да си конфигурираш кода, примерно ако еди кой си символ е дефиниран да се компилира еди какво си... опс... всъщност ти говориш за "област", която е дефинира в опциите на компилатора.. Е па такова животно хептен няма Не знам за области... има "секции", но секциите не се дефинират в компилатора. На ниво компилация не е нужно и не се дефинират секции. Може само да кажеш кой обект в коя секция да бъде. Това става в сорса, не чрез опции. Виж на линкера май може да му дефинираш секции чрез опции, макар че по-разумно е да се ползва скрипт файл. Но хайде първо кажи за какво иде реч, че да не гадая и да не обяснявам неща дето може и да не те интересуват.... |
|
| Автор: | RM [ Съб Сеп 03, 2011 6:03 pm ] |
| Заглавие: | Re: CBS setup |
Нещо съм в грешка Интересуваше ме използването на In-Application Programming (IAP) за дефиниране на FRAM и записване на променливи в определена област от вътрешния flash (10к цикъла) или някъде го четох ЕЕПРОМ емулиране. Въпреки че навсякъде не го препоръчват. Има го в един линкерски скрипт но за LPC2106. |
|
| Автор: | miro_atc [ Съб Сеп 03, 2011 7:15 pm ] | |||||||||||||||||||||||||||
| Заглавие: | Re: CBS setup | |||||||||||||||||||||||||||
Това са съвсем основни неща дето е добре да се научат още преди да седнеш да работиш с GCC Значи компилаторът прави от сорс файл т.н. обектен файл. Подаваш му един сорс файл (само един) и той "компилира" като резултатът от компилацията е списък с обекти, дето се записват в обектния файл. Обектите могат да са някакви глобални променливи, може да са финкции (код). Но важното в случая е компилаторът изобщо, ама изобщо не се интересува дали тия обекти ще разполагат в ROM, RAM, в EXE-файл, DLL, BIN или някакъв друг файл. Може и никъде да не се разполагат, ако не се ползват.... Но това се решава на един малко по-късен етап, наречен линкване... Само да кажа, че компилаторът задава секция за всеки обект. Има няколко секции по подразбиране - за код (.text), за read only (.rodata, .init, .fini) данни и за read-write данни с инициализация (.data) и без инициализация (.bss). Секциите по подразбиране леко варират според версията на компилатора, езика Ц и Ц++ и т.н. И другото което зависи от компилатора е дали всички обекти от даден тип да са в една секция, или за всеки да се прави отделна секция (виж -ffunction-sections -fdata-sections). Това последното е важно, понеже оптимизацията е на ниво секция. Ако нищо от дадена секция не се ползва се разкарва цялата секция, иначе остава цялата. Така че ако искаш неизползваните променливи и функции да се оптимизират, по-добре всеки обект да си е в отделна секция... Сега линкерът.... На него му даваш списък с обектни файлове (и/или библиотеки) и му казваш какво да ти скалъпи от тях. За целта му се задават и някакви правила (обикновено линкер скрипт), чрез които му казваш "вземи тия обекти от тия файлове (входни секции) и ги сложи еди къде си (изходни секции)". Едва при попълването на изходните секции се получават "някакви" адреси. Казвам някакви щото зависи какво точно се скалъпва, иначе адресите са малко виртуални. Секцията може да се разполага на един адрес в bin-файла (или каквото там се генерира) а пък после при зареждане в таргета да е на друг адрес. Тъй... да се върнем на проблема.. Значиш имаш някакви FRAM, EPROM или каквито там памети искаш.... Тия памети са ти на опреден адрес и с определн размер и най-добре в линкерския скрипт да ги опишеш:
После си описваш секциите:
Забележи първата изходно секция my_text_section - в нея казвам да се сложат всички обекти от всички файлове (*) и входна секция ExceptionVectors. После цялата изходна секция се разполага в rom дето по-горе го дефинирахме... За подробности в синтаксиса може да прочетеш ръководството на LD Te по тоя начин може да си правиш всякакви секции и да си ги разполагаш където и както си искаш... Остана само как в сорса да кажеш коя променлива/функция в коя секция да отиде (ако не искаш да е в секция по подразбиране):
В случая масивчето ще отиде в моята секцийка ExceptionVectors, а тя пък ще отиде в началото на rom-а ... Така може от група сорсове да генерираш един, два или повече изходни файлове с каквото съдържание искаш. Имаш контрол върху всичко, ограничен си само от фантазията и знанията си |
||||||||||||||||||||||||||||
| Страница 1 от 1 | Часовете са според зоната UTC + 2 часа [ DST ] |
| Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group http://www.phpbb.com/ |
|