Для начинающих это еще сразу дает образчик дурнейшего стиля программирования с функциями в хидерах, многократно обернутых, зачастую просто небрежно написанных... При этом все запихивается а один файл....Чему это может научить? Ну разве только инлайнить , правда бездумно , даже одну строчку.




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

Нормальный там стиль.
inline функциям как раз и место только в хидерах, они по своей природе равносильны макросам.
Качество кода я тоже демонстрировал - абсолютно ничего лишнего, одного взгляда достаточно для понимания сути. Коментарии тоже в порядке.

А почему бы и нет. Чем это плохо если речь идет о hal функциях. Неужели удобнее цеплять с десяток хидеров, по одному для каждой мелочи типа SPI?

Хоть один компилятор не выбрасывающий неиспользуемые __inline функции можете назвать?

По поводу качества кода: Вы AT91F_PITInit не нашли? Или мы обсуждаем только положительные стороны lib_?

Copy->paste комментарии - это порядок?


А Вам удобно редактировать файл размером 150 кбайт? А если туда еще HAL для EMAC'а и USB запихать - еще удобней станет?


Да, нашел я у себя в закромах Вашу версию lib, AT91F_PITInit там, естественно, есть.

Нашел. Да с Вами можно согласиться - это баг.
Правда ничего ужасающе страшного в нем на мой взгляд нет - вопрос округления.
Для маленьких значений period'a (единицы us) точного значения не будет практически никогда, добавляй туда -1 или не добавляй, на 55Mhz их реализация будет даже более точно работать.
Для больших значений периода доли us не играют роли.

Плюс это не единственная функция для настойки PIT'a в этой библиотеке.

Не коментарии, а шапки функций. Это простительно, на brief редко кто смотрит, а в коде с коментариями порядок.


1. Мне привычно работать с большими файлами.
2. Меня никто не заставляет его редактировать. (зачем его редактировать?)

Ну, тут можно поспорить. Если посмотреть документацию на SAM7, то в ней PITC позиционируется как таймер для точного отсчета интервалов времени:


А в библиотеке для установки этого таймера нам предлагают передать целое число МГц MCK, и вычисляют значение регистра с ошибкой.


Да, есть еще AT91F_PITSetPIV. Если человек способен сам вычислить значение PIV, то вряд ли ему нужны костыли в виде библиотечной функции для установки поля регистра.


Там, где они есть. Беглый просмотр показывает, что часть функций не откомментированна.


За тем, что он содержит ошибки.

Не совсем, компилятор имеет над ними некоторую власть по оптимизации, если конечно специально прагмами типа inline=forced не пользоваться.

Да уж что может быть лишнее, если в подавляющем большинстве там по одной строчке, а там, где уже 3-5 и лишнее, не криминальное, но если позиционировать сей код,как образец, то лишнее

А какая проблема? Тем более,как человек широко использующий тот-же SPI скажу, что SPI использую по максимуму его возможностей а не просто прочитать-записать словечко интерфейс к которому сводят его "библиотеки".

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

имеет конечно. но для того чтобы он имел над ними власть их надо вызвать хотя бы раз.


Вот и я думаю. Чем один файл плох. Какая разница 1 файл или 10 все одно речь о железе.
И еще думаю, что же интересно может помешать создать свой собственный файл не отказываясь от библиотеки.

Вопросом на вопрос - нипойдет.
Хотя
A function where all the declarations (including the definition) mention "inline" and never "extern". There must be a definition in the same translation unit. No stand-alone object code is emitted. You can (must?) have a separate (not inline) definition in another translation unit, and the compiler might choose either that or the inline definition.
http://www.greenend.org.uk/rjk/2003/03/inline.html


Ну и что? ;> С какой радости мне править библиотечный код, который обновляется и поддерживается не мной.

Законы Мерфи помните?
Особо подходящие под этот случай:
3. Все программы содержат ошибки, просто о некоторых мы не догадываемся.
5. Если Вы находите ошибки, исправить которые дело долгое и нудное, ничего не делайте - просто внесите их в список особенностей.
25. Усилия, прилагаемые для исправления ошибки, увеличивают ее в геометрической прогрессии по отношению к затраченному времени.

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

Справедливое замечание. Однако там где нет коментариев, коментировать просто нечего.
Тупые коментарии вида:
a = b; // в переменную a поместить значение переменной b
никому не нужны.

Это относится конкретно к GNU реализации, а отнюдь не ко всем. Посему ответа на вопрос

нет.

Не могли бы вы более подробно описать, как вы это делаете? Ведь AT91C_BASE_XXX описаны через #define и Эклипс просто не видит этих структур.

у меня все прекрасно видится (eclipse 3.4)

...пардон, не заметил слов "при отладке". Возможно автор имел ввиду не отладку, а написание программы...

Сообщение отредактировал injen-d - Aug 20 2008, 16:56

Да, именно в окне watch.

Нужно объявить экземпляр указателя на структуру/тип, когда компилятор сгенерит отладочную информацию. Я пользуюсь at91lib (ленивый программист ), там, в драйверах, они обычно уже объявлены. Для отладки можно глобальный указатель объявить, но я не часто смотрю регистры, мне хватает локальных

И как правильно заметил zltigo, не все регистры одинаково полезно читать