at91, помогите разобраться Опции

[i.dmitry]

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

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

Код

typedef struct _AT91S_PMC {
    AT91_REG     PMC_SCER;     // System Clock Enable Register
    AT91_REG     PMC_SCDR;     // System Clock Disable Register
    AT91_REG     PMC_SCSR;     // System Clock Status Register
    AT91_REG     Reserved0[1];     //
    AT91_REG     PMC_PCER;     // Peripheral Clock Enable Register
    AT91_REG     PMC_PCDR;     // Peripheral Clock Disable Register
    AT91_REG     PMC_PCSR;     // Peripheral Clock Status Register
    AT91_REG     Reserved1[1];     //
    AT91_REG     PMC_MOR;     // Main Oscillator Register
    AT91_REG     PMC_MCFR;     // Main Clock  Frequency Register
    AT91_REG     Reserved2[1];     //
    AT91_REG     PMC_PLLR;     // PLL Register
    AT91_REG     PMC_MCKR;     // Master Clock Register
    AT91_REG     Reserved3[3];     //
    AT91_REG     PMC_PCKR[3];     // Programmable Clock Register
    AT91_REG     Reserved4[5];     //
    AT91_REG     PMC_IER;     // Interrupt Enable Register
    AT91_REG     PMC_IDR;     // Interrupt Disable Register
    AT91_REG     PMC_SR;     // Status Register
    AT91_REG     PMC_IMR;     // Interrupt Mask Register
} AT91S_PMC, *AT91PS_PMC;

далее ниже

Код

#define AT91C_BASE_PMC       ((AT91PS_PMC)     0xFFFFFC00) // (PMC) Base Address

в программе:

Код

    AT91C_BASE_PMC->PMC_SCER = AT91C_PMC_UDP;

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

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

Код

__inline unsigned int AT91F_AIC_ConfigureIt (
    AT91PS_AIC pAic,  // \arg pointer to the AIC registers
    unsigned int irq_id,     // \arg interrupt number to initialize
    unsigned int priority,   // \arg priority to give to the interrupt
    unsigned int src_type,   // \arg activation and sense of activation
    void (*newHandler) () ) // \arg address of the interrupt handler
{
    unsigned int oldHandler;
    unsigned int mask;

    oldHandler = pAic->AIC_SVR[irq_id];

    mask = 0x1 << irq_id;
    //* Disable the interrupt on the interrupt controller
    pAic->AIC_IDCR = mask;
    //* Save the interrupt handler routine pointer and the interrupt priority
    pAic->AIC_SVR[irq_id] = (unsigned int) newHandler;
    //* Store the Source Mode Register
    pAic->AIC_SMR[irq_id] = src_type | priority;
    //* Clear the interrupt on the interrupt controller
    pAic->AIC_ICCR = mask;

    return oldHandler;
}

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

Код

pAic->AIC_IDCR = mask;

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

Код

typedef struct _AT91S_AIC {
    AT91_REG     AIC_SMR[32];     // Source Mode Register
    AT91_REG     AIC_SVR[32];     // Source Vector Register
    AT91_REG     AIC_IVR;     // IRQ Vector Register
    AT91_REG     AIC_FVR;     // FIQ Vector Register
    AT91_REG     AIC_ISR;     // Interrupt Status Register
    AT91_REG     AIC_IPR;     // Interrupt Pending Register
    AT91_REG     AIC_IMR;     // Interrupt Mask Register
    AT91_REG     AIC_CISR;     // Core Interrupt Status Register
    AT91_REG     Reserved0[2];     //
    AT91_REG     AIC_IECR;     // Interrupt Enable Command Register
    AT91_REG     AIC_IDCR;     // Interrupt Disable Command Register
    AT91_REG     AIC_ICCR;     // Interrupt Clear Command Register
    AT91_REG     AIC_ISCR;     // Interrupt Set Command Register
    AT91_REG     AIC_EOICR;     // End of Interrupt Command Register
    AT91_REG     AIC_SPU;     // Spurious Vector Register
    AT91_REG     AIC_DCR;     // Debug Control Register (Protect)
    AT91_REG     Reserved1[1];     //
    AT91_REG     AIC_FFER;     // Fast Forcing Enable Register
    AT91_REG     AIC_FFDR;     // Fast Forcing Disable Register
    AT91_REG     AIC_FFSR;     // Fast Forcing Status Register
} AT91S_AIC, *AT91PS_AIC;

спасибо

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

[aaarrr]

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

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

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

Код

pAic->AIC_IDCR = mask;

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

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


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

[defunct]

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

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

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

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

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

#define pAic AT91C_BASE_AIC
и т.п.

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

[aaarrr]

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

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

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

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

#define pAic AT91C_BASE_AIC

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

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

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

[defunct]

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

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

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

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

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

пример

Код

// Absolute IO access macros
#define pPIOA   AT91C_BASE_PIOA

pPIOA->PIO_PER = LED0 | LED1 | LED2 | LED3;
pPIOA->PIO_CODR = LED0 | LED1 | LED2 | LED3; // set level low

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

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

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

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

[aaarrr]

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

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

Почему же тупейшие. посмотрите
AT91F_PDC_ReceiveFrame
гениальная функция, лучше не придумаешь.

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

пример

Код

// Absolute IO access macros
#define pPIOA   AT91C_BASE_PIOA

pPIOA->PIO_PER = LED0 | LED1 | LED2 | LED3;
pPIOA->PIO_CODR = LED0 | LED1 | LED2 | LED3; // set level low

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

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

Код

*AT91C_PIOA_PER = LED0 | LED1 | LED2 | LED3;
*AT91C_PIOA_CODR = LED0 | LED1 | LED2 | LED3; // set level low

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

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

[defunct]

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

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

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

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

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

Код

*AT91C_PIOA_PER = LED0 | LED1 | LED2 | LED3;
*AT91C_PIOA_CODR = LED0 | LED1 | LED2 | LED3; // set level low

Дык, тут буков больше!
в моем варианте, набор набираемых мной любимым буков:
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 раньше, и первый раз смотрит на код.

[aaarrr]

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

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

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

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

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

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

Как осмысленные названия функций могут быть менее читаемыми чем использование регистров?

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

Неужели
*AT91C_PMC_PCDR = 1 << AT91C_ID_TWI;
прозрачнее для понимания чем
AT91F_PMC_DisablePeriphClock( pPMC, 1 << AT91C_ID_TWI);

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

Взгляните на это с т.з. человека который в глаза не видел AT91 раньше, и первый раз смотрит на код.

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

[defunct]

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

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

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

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

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

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

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

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

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

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

(работая с SAM'ами, никогда даже не пытался запомнить все регистры).

Ему-то как раз все равно,

Мы этого не знаем наверняка, может ему надо найти баг в чужом коде.

поэтому я и пытаюсь прививать людям правильный подход.

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

[aaarrr]

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

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

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

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

А для читавших и забывших даташит? Или единожды прочитав ДШ Вы помните все регистры назубок?

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

[injen-d]

Взгляните на это с т.з. человека который в глаза не видел AT91 раньше, и первый раз смотрит на код.

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

[aaarrr]

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

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

На мой взгляд, одной из самых полезных функций является AT91F_AIC_ConfigureIt ().

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

[injen-d]

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

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

Мне lib_AT91 здорово помогла при освоении SAM7.

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

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

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

[aaarrr]

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

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

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

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

И вот в случае, когда возникают сомнения, например в предназначении того или иного регистра (а в SAM7 таких случаев предостаточно) как раз и помогла lib_AT91. Ни о каком тупом копировать/вставить речь не идет.

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

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

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

[zltigo]

Мне lib_AT91 здорово помогла при освоении SAM7....

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