Это Вы к чему? Здесь описано только ограничение на количество параметров.

6.5.2.2:


6.10.3:




Это не из lib_.


Это, как бы так помягче выразиться, мартышкин труд, Вы не находите?

Опять таки, выясняется, что есть разные версии этих библиотек. Тихий ужас.


Против структур я ничего не имею, если забыть про дурацкие названия с префиксом "AT91S_".

Причем о качестве написания библиотек тоже можно поговорить. Специально не искал, но вот прям сейчас попался на глаза кусок написанный для совсем дугого контроллера (LPC), но тоже с "библиотекой" от NXP/Keil Это инициализация контроллера прерываний:

Муть голубая, промежуточные переменные, пару совершенно лишних сущностей ввиде констант VIC_BASE_ADDR, VECT_ADDR_INDEX, *4, неверный комментарий "find..", отсутствие явного назначения IRQ.
Ну и чего можно постичь читая такой совместный труд двух нехилых фирм NXP и Keil (на самом деле какой-то "индийский" студент писал)? По функционалу тоже вопросы - а разрешение прерываний (последняя строчка)сразу это всегда и всем надо? А прерывания по фронту никому не нужны?
Что-то похожее на образец и отражающее суть железа:

Хотя какого черта эта функция нужна в таком виде не понятно, ибо все сводится при начальнй инициализации к двум/трем простым и совершенно понятным (в отличии от выше приведенной ) после беглого взгляда на datasheet строчкам:


P.S.
Я совершенно не являюсь безусловным противником подобного подхода, например у меня есть подобная функция - она для меня скрывает нюансы реализации контроллеров прерываний LPC21xx и LPC23xx.

Я бы ещё строчку
перенёс после else

А смотрю на текст много, много, много больше нежели на окошки "watch", а на регистры вообще не смотрю, ибо некоторые из них вооще-то не расчитаны на "посмотреть" без побочных последствий.





Да, пропустил - тоже прикол - сначала лупим по регистру, а потом смотрим а параметр допустим был? В догонку - а приоритет на допустимость контролировать не будем , хотя номер будем. В общем славная такая "библиотека" для запудривания мозгов.

Аналогично Но мне структуры в этом не помеха, и даже наоборот. По правде говоря, регистры активно смотрел только когда осваивал новый микроконтроллер. Было наглядно, почти как в AVR Studio. Не вижу принципиальных причин, за исключением особых случаев, чтобы не посмотреть значения регистров, если периферия ведет себя как-то не так. Иногда это позволяет найти ошибку посмотрев текст уже не так много, много раз

Зато в тексте явная помеха рассматривать дикие длиннющие названия пытаясь вычленить из них не очень-то и сами посебе благочитаемые аббревиатуры - в глазах рябит.

Ну, не обязательно писать "AT91C_BASE_PITC->PITC_PIMR = x", можно и "*AT91C_PITC_PIMR = x", а можно, после простой доработки хидера напильником, и "PITC_PIMR = x".

Использовать аббревиатуры было не лучшей идеей Атмела, но тут уже ничего не исправить.

Вот доработанные до нормального состояния и пользую. Тоже для LPC/IAR "дорабатываю" алиасы битов...

Почему? Отредактировали-же . А идея проста - выдрессировать и привить дурную (вроде курения) привычку пользоваться их ARM продукцией

Не думаю, что кривизна хидеров и библиотек была преднамеренной. Но создавались они в купе с примерами именно с этой целью.

Не обязательно. Это дело вкуса. Мне удобней так:

hal.h:
#define pPITC AT91C_BASE_PITC
#define pPIOA AT91C_BASE_PIOA
#define pEMAC AT91C_BASE_EMAC
#define pTimer1 AT91C_BASE_TC1
....

#include "hal.h"
pPITC->any_reg = x

А в записях вида:

преднамерено делается разгруппировка уже сгруппированных по смысловой нагрузке (по периферийным блокам) регистров. Смысла - 0, разве только понизить гибкость модификации кода, за счет мифической наглядности.

"Мифической" потому что вы так и не сказали чем отличается наглядность между
PITC_PIMR = x
и
pPITC->PITC_PIMR = x

Зато сгруппировать блоки в структуры - очень правильная идея.



А от коротких регистров не рябит?

EKLMN = x;
EPRST = y;

Как по мне - пусть название будет длинным, но в нем будет сказано все для понимания этой строчки через год, два, десять лет.


Речь даже не о watch. Любой нормальный редактор умеет открывать структуры - и показывает их нутро в параллельном окошке типа object explorer etc. Так имея указатель на структуру регистров того же VIC'a, вы автоматом (смотря текст, а не watch) увидите какие еще регистры относятся VIC'у, без лазиния по ДШ и без, лишний раз, заглядывания в хидеры.
Ниже наглядный пример того о чем я говорю (скриншот ~200kb)

Смысла фразы про группировку не понял абсолютно - какая разница, обращаюсь я к переменной напрямую, или в составе структуры через указатель? Чем плох первый вариант, поясните.

Замена одной строки на другую дефайном никак гибкости модификации не добавляет.
Тогда уж лучше пишите, как в lib_AT91:

Это будет гибким решением, достаточно будет поменять аргумент при вызове.


А где это я говорил про наглядность? Хотя влияет, конечно. Сравните
PITC_PIMR = x
и
AT91->SAM7X->BASE_PITC->PITC_PIMR = x


Кстати, я сам пишу "AT91C_BASE_PITC->PITC_PIMR = x". И меня это уже давно не утомляет.


Длиннее не значит понятнее: 50% людей не знают точно, как расшифровывается PIO_PDR - Peripheral Disable Register или PIO Disable Register. Очень распространенная ошибка.


Если Вы не помните, какие еще регистры относятся к VIC (что предполагает, что Вы добавляете какую-то функциональность), то прямой это повод обратиться к ДШ.

Вы находитесь на правильном пути, раз AT91C_BASE_PITC Вам не удобны

Смысловая группировка совершенно абстрактна и ничего дополнительного не несет совершенно, ну к чему повторения в Вашем варианте "pPITC->PITC_PIMR" аббревиатуры PITC дважды? Чем это масло-маслянное облегчит "понимания этой строчки через год, два, десять лет"? К чему бессмысленное и ошибочное (ибо это не указатель и любой нормальный человек увидев указатель напишет *pPITC->PITC_PIMR = x) в "венгерском" стиле добавление 'p'?

Однако, я про наглядность не говорил, я говорил и говорю про неудобочитаемость.

Вы как-то это повторяете и повторяете...,как мантру. Себя пытаетесь убедить?

Меньше.

Любой нормальный редактор покажет и нормально написанный хидер по тэгу - никаких проблем.



Человек ко всему привыкает, но я себя любимого люблю больше, посему так не пишу

zltigo и aaarrr
Я там выше прикрепил рисунок. Собсно о чем я говорю. Когда я навожусь на имя регстра после "->" мне открывается стркуктура (в данном случае emac), где все регистры с коментариями как на ладони.


По крайней мере я сразу смогу окинуть взглядом все регистры этого PITC.
Более наглядный пример - канал DMA (которых больше десятка и все они имеют одинаковые регистры), здесь так и просится работа с указателем на DMA канал. Тоже самое с таймерами которых 3, с уартами и т.д.


Ну раз уж со стороны уже так кажется, то пора завязывать.


в этой теме все крутится вокруг
lib_AT91 - которую некоторые рекомендуют выбросить и забыть как книжку Редькина
и вокруг "->" (тут уже imho безосновательно).
Я уже наверное 10 раз повторился, что это дело вкуса применять их или не применять и нет единственно правильного стиля.

Atmel'цов тоже понять можно. Не могут они обозвать свои типы PTIMER / PPDC/ PEMAC и т.п., т.к. вполне резонно предположить, что разработчик использующий ихнее добро сам захочет использовать такие имена в своем проекте. Вот и накрутили они эти AT91C / S / PS.

Да понял я, понял. Это не секрет . Рисунков прикреплять не буду, но при запросе по имени тэга под курсором я получаю все нужное и естественно тоже с комментариями, поскольку в хидере у меня все тоже сгруппировано и откомментированно. Причем это механизм универсальный и работает при описании собственных битов для, например, чего либо подобного GPIO и с алиасами.

P.S.
Извините, я случайтно удалил из Вашего поста несколько уточняющих строк


Просится не просится, но Вы, простите, пользуетесь НЕ указателями . Посему никакого удобства не имеется. Если мне потребуется я спокойно получу и передам указатель, то-же самое придется сделать и Вам с Вашей записью На предложение ради этого всегда писать в стиле *pAT91C_BASE_PITC->PITC_PIMR = x я даже отвечать не буду.

Драсти, а чем тогда я пользуюсь? ;>
То чем я пользуюсь (то чем нас Atmel порадовал) AT91C_BASE_XXX - константные указатели на структры регистров периферийных модулей XXX.


это уже через чур, и согласен, даже не подлежит обсуждению, из-за неэффективного использования памяти.