Здравейте,

Ползвам uVision. Търся алтернативен хедър файл за LPC17xx процесорите, защото не ми харесва как са дефинирани регистрите за Cortex процесорите. Т.е. трябва ми файл където са дефинирани с точни адреси, а не като част от структури (както са ги направили за ARM7 процесорите).

Трудно, то по принцип за кортексите използват CMSIS като стандарт, та от там тръгва твоя проблем ... и подозирам, че от каквато и среда да ги извадиш тия .h файлове все така ще са описани. Какво ти пречат структурите за достъп?

Много по-дълъг е записът, особено когато искаш да се обърнеш към конкретен бит. А и не разбирам, защо са избрали подобен начин като по-добър.

Ами защото това е по-добрият и по-правилен начин

Има много причини:
1) По-малко и по-кратки дефиниции. Обикновено имаш повече от 1 контролер от тип. Примерно 4-5 UART, две USB-та или 7-8 GPIO контролера.
Перифериите имат грубо 20-100 регистъра. Ако се ползва структура се получава само 1 структура с толкова елемента колкото регистри има. Така един регистър се описва веднъж, а не 4-5 или 8 пъти!

2)По-кратък и по-ефективен код. Ако имаш 4 UART-a не пишеш 4 функции за пращане дето да правят едно и също. Пише се една функция (или драйвер).
Но дори и само 1 UART да имаш, пак е по-ефективно чрез структури понеже рядко функцията ще ползва само 1 регистър. Функция, която работи с структура се компилира с 1 указател за всички (или повечето) регистри. Докато ако ползваш адреси за всеки регистър те ще се извличат многократно.
Така че както и да гледаш кода чрез структури е по-добър...
Отделно и при дебъгване е по-удобно и дори дамо като стил на писане пак е по-правилно чрез структури.

+1 Много по-удобно е, дори и ако предефинираш указателя - с един ред можеш да преназначиш функцията, към която си искаш периферия. И е толкова по-нагледно и организирано ... жалко, че тоя стандарт го нявмаше при 7-ците, щеше да е много по приятно и лесно за портване (а това последното си е важно).

Как бе, при моите седмици винаги си го е имало

Иначе портването е също много сериозна причина. Примерно при Атмел ползват едни и същи периферии както за 7-ци така и за 9-ки и за куртекси. Общо над 200 различни чипа ползват един и същ тип UART с различни бройки на чип, естествено различни адреси...
Но ако погледнете последните версии на библиотеките имат само един единствен хедър файл за UART. Не 200+ а само един, който може да се ползва от над 200 чипа. За чиповете има само по един мапинг файл, в който се декларира какви периферии (структури) на какви адреси има.

Долу горе хедърите на Атмел са едни от най-читаво направените. Единствения проблем е че имат две версии, но това си е техен проблем...А пък хедърите за CMSIS са пълен ташак. Най-вероятно индийци са ги писали, а те са противоположното на думичката "стандарт"..

Да, съгласих се за момента за изпозлването на няколко UART-а и т.н.

Има едно нещо:
LPC_SC->SCS |= (1 << 5);
SCSbits.OSCEN = 1;

Вторият запис не ви ли се струва по-удобен за писане?

Въпросът не е какво ни се струва и какво не ни се струва... Има си правила!

Ето някои:
1) Най-важното е именуването. Направо се изприщвам като чета код от Луминари. Гледаш вдигат някакъв бит в някакъв регистър. Пускаш търсене в дейташита нито регистъра го има, нито бита. Естествено ги има, но под друго име и ти отнема сума си време да ги намериш. Както и обратното като четеш дейташита и искаш да провериш еди кой си регистър дали и как се пипа от софтуера трябва да стане с търсене в проекта. Това е просто задължително, но за целта имената от хедърите трябва да отговарят на имената в дейташита.
Подчертавам, това не е въпрос на "удобство" или на "струване"...

2) Естествено хедърите се правят със структури и универсални, така като имаш код за дадена периферия да не се налага да го пипаш ако смениш чипа и/или проекта.

3) Хедърите трябва да са универсални както за Ц, така и Ц++, така и асемблер. Аз в началото правех отделно за Ц/Ц++ и отделни за асемблер (заради структурите). Но има начин да е един хедъра и по-добре да е един.

4) Хедърите трябва да са документирани. Стандартът е doxygen и почти всички имат "нещо", което е по-лошо и от нищо, защо ако не бяха ползвали doxygen кодове поне нямаше да бълва толкова грешки.

-------
Нямам в момента дейташит на това LPC, но правилният запис е:

указател->ПЕРИФЕРИЯ_РЕГИСТЪР |= ПЕРИФЕРИЯ_РЕГИСТЪР_ФЛАГ;

където нещата с главни букви трябва да са изписани точно както е в дейташита!!!
Действително, тоя запис става малко по-дълъг, но затова трябва да мисли тоя който пише дейташита, а не ти... Ти трябва да мислиш какво ще правиш няколко години след като си написал кода и той е набъбнал над 100хил или 1млн. реда