Помогите разобраться, пожалуйста.

в Header AT91SAM7S256.h файле написано:


далее ниже


в программе:


правильно ли я понял, что AT91PS_PMC - указатель на структуру_AT91S_PMC.
AT91C_BASE_PMC - ее начальный адресс,
строчка в программе означает, в регистр PMC_SCER (по адресу AT91C_BASE_PMC + 5*AT91_REG) записать значение AT91C_PMC_UDP?

-----------------
теперь файл: lib_AT91SAM7S256.h



как компилятор узнает адрес регистра AIC_IDCR?


ведь pAic это есть AT91PS_AIC, но на какой начальный адрес он указывает НЕТ в библиотеке


спасибо

Сообщение отредактировал i.dmitry - Aug 15 2008, 19:10

Правильно, только адрес будет просто AT91C_BASE_PMC.


Функция принимает этот адрес как параметр, в чем проблема?


P.S. А lib_AT91SAM7S256.h лучше не использовать - код сразу станет нечитаемым.

Я напротив, считаю что библиотеку использовать стоит.
Это только с непривычки и если использовать текстовый редактор типа "notepad" - тогда будет нечитаемо.
А если редактор нормальный, и показывает тело функций при наведении на них, то нет проблем, сразу видно и параметры и коментарии к каждому параметру. Да и имена функций сами говорят за себя.


pAic это параметр функции, указатель на структуру AT91S_AIC (в объявлении типа они добавляют P перед S, и получается AT91PS_AIC - AT91 Pointer to Struct AIC) . Адрес самого AIC'а указан в библиотеке как AT91C_BASE_AIC. Зачем так сделано - на случай если вдруг будет несколько AIC'ов.
Как например есть несколько каналов DMA.

Можете как для себя переопределить узлы с которыми работаете как

#define pAic AT91C_BASE_AIC
и т.п.

А вообще если разобраться с библиотекой то код получается мало того что хорошо читаемый, так еще и запуск/настройка любого периферийного узла занимает максимум 5 минут (с открытой страницей даташита и поиском по библиотеке).

Скажите, а форум мне покажет тело функции при наведении на нее?

Да и функции тупейшие, смысла их использовать просто нет.


Гениально! Врагу не пожелаю разбираться с таким кодом.


Запустите мне USB или EMAC за 5 минут, пожалуйста.

Копируем текст в свой любимый редактор, наводимся - и все как на ладони. Библиотека то стандартная.

Почему же тупейшие, смею обратить ваше внимание на
AT91F_PDC_ReceiveFrame
гениальная функция, лучше не придумаешь. По ней сразу видно как надо работать с DMA даже без вникания в ДШ. И таких премеров много.


пример

трудно читаемо?

При написании кода есть неоспоримые плюсы.
1. Писать быстрее - имя периферийного модуля задано так как удобно мне, code completion делает все остальное. (pPIOA-> редактор дает список всех регистров именно этого периферийного модуля, остается только выбрать).
2. Возможных механических ошибок меньше. При написании pPIOA редактор показывает описание структуры (а следовательно сразу видно коментарии к регистрам), и не нужно помнить какой за что отвечает.


Это пожалуй исключения. Для этих модулей я и сам предпочел не использовать AT91F функции.
Но для всего остального, PMC, PDC, AIC, PIO, TIMERS, SPI, UART и т.п.. почему бы и нет. Экономит время.

В своем любимом редакторе я не использую lib_AT91. И не думаю, что это моя проблема.


Посмотрел. Описание функции в стиле copy->paste Ничего гениального в ней не вижу, хоть убейте.


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



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

Это предмет личных предпочтений, а никак не повод для обвинения библиотеки в трудночитаемом коде.


Там алгоритм загрузки указателей DMA. Можно ничего не читая про DMA правильно с ним работать! В этом и прелесть.


Дык, тут буков больше!
в моем варианте, набор набираемых мной любимым буков:
pPI[enter]->PIO_x[enter] (12 и них 4 "->" и "enter" повторяющиеся)
в вашем:
*AT91C_PIOA_x[enter] (14 из них 1 "enter" повторяющийся)


Подглядывать придется в обоих случаях, как минимум определения регистров искать.
Имена библиотечных функций отражают ровно то, что делают функции.
AT91F_ADC_CfgTimings
AT91F_ADC_EnableChannel
AT91F_TC_Open
AT91F_PIO_CfgOpendrain
и т.п.
делают то, что написано простым англ. языком .
Как осмысленные названия функций могут быть менее читаемыми чем использование регистров?

Неужели
*AT91C_PMC_PCDR = 1 << AT91C_ID_TWI;
прозрачнее для понимания чем
AT91F_PMC_DisablePeriphClock( pPMC, 1 << AT91C_ID_TWI);
Взгляните на это с т.з. человека который в глаза не видел AT91 раньше, и первый раз смотрит на код.

Я не библиотеку обвиняю, а её пользователей, которые...


...даташиты не читают. А потом задают вопросы с приложением чудовищного кода.


И не лень было подсчитывать


Очень просто: для работы с регистрами нужен только даташит, для работы с функциями - даташит и исходники функций.


Для читавших даташит прозрачнее. И букв меньше


Ему-то как раз все равно, поэтому я и пытаюсь прививать людям правильный подход.

С этим протестом согласен. ;>

Кстати я не спроста привел ReceiveFrame в качестве примера. В этом форуме столкнулся с крайне бездарной работой с DMA с помощью регистров. IMHO лучше бы автор того убогого кода пользовал lib_AT91.
Чудовищный код оставим на совести его авторов, библиотека тут не при чем.


Спать не хочется. Остается буквы считать (как слоников перед сном )
На самом деле более весомые как для меня арументы в пользу pXXX-> я указал выше. Регистры модуля сгруппированы и отображаются code completion'ом.+ клик на структуре показывает все регистры модуля с коментариями.


Не принимается:
Для отладки программы можно использовать светодиод. А можно UART, JTAG и светодиод, от этого наглядность отладки не пострадает.

IMHO - самый читабельный вариант это когда достаточно только исходников.


А для читавших и забывших даташит? Или единожды прочитав ДШ Вы помните все регистры назубок?
Я вот сейчас уже не помню большинство регистров 51-го. Ловлю себя на мысли, что придется лезть в ДШ для того чтобы разобраться в своих же старых программах , где используются регистры. Так что как для меня - функции прозрачнее.

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

Это несколько разные вещи. От использования лишних хидеров наглядность программы пострадает однозначно.


Вот именно. И желательно в одном файле


Как ни странно, большинство помню. И использование библиотеки никак не избавляет от необходимости знать архитектуру и помнить/смотреть описания регистров.

+1 defunct.
Мне lib_AT91 здорово помогла при освоении SAM7. Даже если гдето и не использовал функции из lib_AT91 то почти всегда туда заглядывал, чтобы подсмотреть как правильно сконфигурировать тот или иной модуль. Сейчас lib_AT91 использую примерно в 60% случаев. На мой взгляд, одной из самых полезных функций является AT91F_AIC_ConfigureIt ().

По-моему, для правильного конфигурирования модуля нужно прежде всего представлять себе его работу, для чего есть даташит. А подглядывание/копирование чужого кода этому не способствует.


А мне проще написать 4 строчки или меньше, т.к. предварительно запрещать прерывание (запись IDCR) нужно далеко не всегда, а очищать перед разрешением (запись ICCR) не нужно почти никогда.

Ну во-первых, понимание работы переферийных модулей у программиста "выросшего" из железячника (коим я являюсь) никогда не вызывало проблем. Это удел, в основном, бывших системных программистов. Во-вторых, не все в школе учили английский, поэтому не все могут однозначно и правильно понять, что написано в англоязычном даташите. И вот в случае, когда возникают сомнения, например в предназначении того или иного регистра (а в SAM7 таких случаев предостаточно) как раз и помогла lib_AT91. Ни о каком тупом копировать/вставить речь не идет.
Обращаю Ваше внимание на следующее предложение в моем предыдущем посте:



А велика ли потеря? Конечно если не нужны какие-то действия, производимые в функции AT91F_AIC_ConfigureIt (), то я согласен - можно написать свой код. Но новичков, на этапе освоения использование функций из lib_AT91 может предостеречь от некоторых ошибок, труднообнаружимых на начальном этапе освоения.

Сообщение отредактировал injen-d - Aug 17 2008, 13:05

Далеко не все выросли из железнячников, да это и не гарантирует понимание на самом деле.


О необходимости знания анлийского языка было уже сказано очень много. Уважающий себя инженер обязан знать его в объеме, требующемся для однозначного понимания даташита.


Если не трудно, приведите пример. Ну не знаю я в SAM'ах регистров, назначение которых может быть не понятно.


Велика - спать спокойно не смогу
От каких ошибок может предостеречь использование AT91F_AIC_ConfigureIt?

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