Нет Вы не правы. Макросы вот такие:
((AT91PS_EMAC) 0xFFFDC000)
эквивалентно:
((Struct *) 0xFFFDC000)

т.е. это честные указатели на группы регистров.


Если Вы про Редькина, то я согласен.

Нет, как не трудно догадаться, не про Редькина. Хотя его книжкам самое место в печке.


Я тоже. Мозг требуху типа AT91S_ фильтрует достаточно легко.

О чем и речь .

Насчет же lib_AT91 я также приводил обоснованные примеры где ее использование сокращает уйму времени - ADCConfigureTimings, PDC_ReceiveFrame (да и все что связано с DMA), все без исключения xx_Configure хотя бы в образовательных целях. Имена функций более вменяемые по-сравнению с названиями регистров "EPRST" и иже с ним.

если это указатели, то запись
pNAME = x присваивает значение УКАЗАТЕЛЮ а не обьекту . Посему вычитывайте макросы дальше до прояснения написанного в них.

Какой толк в таком "образовании"? Сами же писали, что можно использовать PDC_ReceiveFrame и забить на чтение документации.
Вот научится человек ADCConfigureTimings вызывать и никогда не узнает, как этот ADC работает.

Я тоже привел обоснованный пример где функция из lib_ содержит 2 ошибки.

это константный указатель.
pBASE_NAME = x - не имеет смысла вообще.


#define X (U32 *)(0xFFFF0000)

X = x; <- не имеет смысла
*X = x; пишем x по адресу 0xFFFF0000.



typedef struct tagMYSTRUCT
{
U32 x, y;
} *PMYSTRUCT;

#define X ((PMYSTRUCT) 0xFFFF0000)

X - структура из элементов x, y по адресу 0xFFFF0000
X = z; - не имеет смысла.
X->x = z; пишем z по адресу 0xFFFF0000
X->y = z; пишем z по адресу 0xFFFF0000 + 4

Может стоит освежить знания языка? А то, право, как-то странно общаться . Константный, не константный дело второе.

Ага, но именно ТАК Вы пишите и работает по той причине, что это на самом деле НЕ указатель (мамнадчатый раз уже пишу) хотя перед ним и у Вас ОШИБОЧНО стоит 'p' а выражение эквивалентное:
*pBASE_NAME = x;


Может стоит освежить знания языка? А то, право, как-то странно общаться . Константный, не константный дело второе.

Ага, но именно ТАК Вы пишите и работает по той причине, что это на самом деле НЕ указатель (мамнадчатый раз уже пишу) хотя перед ним у Вас и стоит 'p'. Это, простите, Ваш "стиль" и Ваш код с котрого все началось:

Так какому из Вас теперь верить .

Забить? я прямо так и сказал? Не может быть.
Вот мои слова:

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

Честно сказать, я не нашел функций на которые Вы ссылались в моей библиотеке, поэтому не могу ни подтвердить, ни опровергнуть.
//* Generated : AT91 SW Application Group 09/12/2005 (15:39:14)



ок давайте освежим
это что:
(int *)(0xFFFF0000)


'p' там правильно стоит.
Выражение эквивалентное *pBASE_NAME = x; - запись ПО адресу pBASE_BAME.



Как так?
pPITC->PITC_PIMR = x; != pPITC = x;

pPITC->PITC_PIMR = x; == *((U32 *)pPITC + PIMR_OFFSET) = x;

А это, интересно, чьи:



Google по этой строчке находит at91sam7x256.h. Неужели в одну секунду lib_ и .h сделали?

Фраза, выдранная из контекста меняет смысл полностью. Я не давал рекомендаций забивать на документацию нигде. В оригинале было:

Упор был на то, что достаточно сложный модуль можно использовать без елозиния по ДШ часами.


Я так понимаю это дата всего пакета.
//* File Name : lib_AT91SAM7X256.h
//* Object : AT91SAM7X256 inlined functions
//* Generated : AT91 SW Application Group 09/12/2005 (15:39:14)

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

Бывает

Контекст здесь только уточняет, что можно пользоваться алгоритмом не читая документацию. Смысл не меняется.


PDC сам по себе простой, как грабли - полное описание занимает 2 страницы.


ОК. И что, в ней нет функции AT91F_PITInit?

У меня:

нет


Да, алгоритмом пользоваться можно. Смысл меняется кардинально. Документация создается для описания устройства и алгоритмов работы с ним, а в ReceiveFrame мы имеем описание алгоритма 10-ю строчками. Чем в таком случае lib_ не удовлетворяет понятию документация?


Простой, но тем не менее многие делают типичную ошибку - загружают только 1 указатель.

Кстати, совершенно нагляднейший пример сбоя в мозгах при натыкании на непривычный синтаксис абсолютно чуждый (мне по крайней мере ) 'p' увидел и "все" ....

Странно, в более ранней есть.



В ReceiveFrame мы не имеем никакого описания, даже brief скопипасчен и не исправлен:



Это не ошибка. Если я, например, хочу передать 1 пакет через UART, то второй указатель мне и не нужен.

А в блаженные времена AT91M40800 второго и не было.

Перепроверю завтра.

Там самодокументируемый код описание прямо в нем (см. имена функций и переменных):

Дык, мы ж о ReceiveFrame говорим Приход данных от нас не зависит.
Времена поменялись, народ забывает использовать NextBuf даже при непрерывном чтении.

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


Хорошо, хочу принять данные из SPI. Так устроит?

Надо чтобы кто-то третий взглянул, желательно перед и после прочтения ДШ. А то у нас с Вами субъективные взгляды.

Ок, это исключение

Я бы несколько по-другому поставил вопрос. Полезно ли embedded разработчику наличие lib_xxx или вы считаете, чтобы лучше ее и не было? Пожалуй, все таки полезно.

Тем, кто имеет слабость лениться думать самостоятельно, наличие этой библиотеки может навредить. А для остальных использование lib_ просто лишено смысла по причине примитивности функций и простоты периферии SAM'ов.

Как разработчик я бы предпочел иметь от Atmel'а пустую errat'у, а не сомнительного качества библиотеку.

Сами Atmel'цы от нее, похоже, отказались. В последних AT91 Software Package и at91xxx_getting_started нет lib_xxx, но есть at91lib, на которую от наших Гуру, насколько можно представить, будет/есть не меньше нареканий А что поделаешь?! Индийским студентам тоже надо кушать

Работаю в Crossworks, хотелось бы поработать с lib_1t91sam7xxx.h, но при объявлении сия заголовочного файла в нескольких исходниках на си компилер ругается, ссылаясь на Multiple definition of, как этим бороться? Пробывал объявить extern, та же фигня..( Заранее благодарен!

И работали бы спокойно дальше.

Мне интересно, что для Вас изменится с использованием этой "библиотеки"? Какие плюсы Вы видите?


Хидер защищен, проблем с multiple definition быть не должно. Куда Вы пытались прикрутить extern???

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




Да линкер у него ругается, когда находит кучу продублированных функций - всегда безусловно инлайнить компиляторы не обязаны, как впрочем и выбрасывать неиспользованые функции, хоть они и с __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)
Нажмите для просмотра прикрепленного файла
...пардон, не заметил слов "при отладке". Возможно автор имел ввиду не отладку, а написание программы...

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

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

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