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....

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

[injen-d]

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

Если Вы, когда начали изучать SAM7, имели достаточный опыт, или хотя бы у Вас неподалеку находился знающий коллега, который всегда подскажет, то никаких проблем, все понятно. А если не хватает опыта и некому подсказать, то даже совершенно пустяковые сомнения в правильности своего понимания проблемы могут стать серьезным препядствием и положить начало "копанию" не в ту сторону.
У меня, например, помню случались сомнения в правильности выбранной мной последовательности программирования регистров модуля при конфигурировании, и тут "подглядывание" в lib_AT91 помогало быстрее, что называется на примере, разобраться с проблемой.

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

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

[SpiritDance]

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

[injen-d]

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

Удивляет безкомпромиссность и безаппеляционность мнений наших Гуру. Да я согласен, что lib_AT91 далека от идеала в плане эффективности и целесообразности использования ее функций, но в качестве наглядного примера по конфигурации каждого модуля, для новичка она все таки имеет некоторую полезность.

[aaarrr]

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

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

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

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

Помоему, спор уже идет о вкусах, или спор ради спора. Неконструктивно.

Для меня это не спор ради спора, а попытка съэкономить себе время и нервы в дальнейшем.

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

Так это еще и новый стиль, оказывается. Куда катится этот мир?

Действие сразу понимаешь, когда видишь регистры и то, что в них пишется, а не однотипные ConfigureIt, EnableIt и т.п.

[defunct]

Для меня это не спор ради спора, а попытка съэкономить себе время и нервы в дальнейшем.

Не понимаю каким боком чужой стиль касается Вас?!

Стиль который Вы пропагандируете по своему хорош, (уверен многие присматриваются к вашим примерам и пытаются делать также), но не стоит его навязывать.

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

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

[aaarrr]

Не понимаю каким боком чужой стиль касается Вас?!

Просто вижу часто и погружаюсь в депрессию

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

Если не знать/забыть содержимое функции (что гораздо вероятнее), то её название скажет не больше.

Напишу я, например:

Код

AT91F_PITInit(PIT, mck, 1000)

И что, понятно, что оно делает?

[defunct]

Если не знать/забыть содержимое функции (что гораздо вероятнее),

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

Напишу я, например:

Код

AT91F_PITInit(PIT, mck, 1000)

И что, понятно, что оно делает?

Импровизирую - инициализирует PIT. (навскидку не вникая в регистры с периодом 1000 тиков частоты mck).
Если будет нужно точнее, подсмотрю в исходниках.

[sergeeff]

Ну я бы еще отметил следующие. Atmel, особенно в последнее время, приводит достаточно много примеров по использованию своих процессоров. Так вот их использование или просто тестирование с использованием lib_xxx проще и быстрее.

[aaarrr]

Ипровизирую - инициализирует PIT. (навскидку не вникая в регистры с периодом 1000 тиков частоты mck).

Все так, за исключением ряда моментов

1. не 1000 тиков а 1000мкс.
2. частота задается в мегагерцах (вот удобно - где-то в Гц, а где-то в МГц).
3. функция содержит ошибку, так как реальный интервал таймера PIT равен не PIV, а PIV+1.
4. я сделал ошибку, переставив 1000 и mck местами.

А в такой записи все как на ладони:

Код

#define PIT_HZ    1000

AT91C_BASE_PITC->PITC_PIMR = AT91C_PITC_PITEN | AT91C_PITC_PITIEN | ((mck + PIT_HZ * 8) / (PIT_HZ * 16) - 1);

Клянусь, функцию специально я не выбирал, и ошибку с PIV заметил только что.

[zltigo]

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

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

Удивляет безкомпромиссность и безаппеляционность мнений.....

Дык я тоже назвал целых два случая полезности таких "библиотек". А вообще причин появления таких приблуд несколько:
- Профессия программист стала массовой, но само слово уже не значит почти ничего;
- Куча "программистов" программируют вызывая некие функции API, OS, "драйверов", "библиотек" добавляя от себя 2+2=
- Производители хотят привлекать низкоквалифицированных программистов;
- Используя таких "программистов" и подсаживая их на какие-то библиотеки, copy-paste, дикие (но человек ко всему привыкает) конструкции типа AT91C_BASE_PITC->PITC_PIMR производитель чипов привязывает их и к своим контроллерам.
Многие довольны.

...их использование или просто тестирование с использованием lib_xxx проще и быстрее.

Про тестирование "схемотехником" согласен, а вот разумное использование возможностей железа крайне затруднено .

[sergeeff]

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

[zltigo]

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

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

[aaarrr]

Еще один показательный пример для любителей lib_AT91

[sergeeff]

Еще один показательный пример для любителей lib_AT91

Нормальный компилятор не должен ругаться на число параметров > 4 (ISO/IEC 9899 : 5.2.4.1 Translation limits -> 127 parameters in one function definition).

Ни в одной из имеющихся в моем архиве lib_xxx не обнаружил AT91C_BASE_AIC->AIC_IMR = 1 << AT91C_ID_PIOA;

Очевидно, что в lib_xxx полно ошибок. А кто мешает их исправить и пользоваться дальше?

[SergeiCh]

По мне структуры хороши хотя бы тем, что при отладке в Eclipse/Insight позволяют очень удобно смотреть содержимое регистров. Лучшего способа, чем добавить такую "сущность" в watch, я просто не знаю.

[aaarrr]

Нормальный компилятор не должен ругаться на число параметров > 4 (ISO/IEC 9899 : 5.2.4.1 Translation limits -> 127 parameters in one function definition).

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

6.5.2.2:

If the expression that denotes the called function has a type that includes a prototype, the
number of arguments shall agree with the number of parameters. Each argument shall
have a type such that its value may be assigned to an object with the unqualified version
of the type of its corresponding parameter.

6.10.3:

If the identifier-list in the macro definition does not end with an ellipsis, the number of
arguments (including those arguments consisting of no preprocessing tokens) in an
invocation of a function-like macro shall equal the number of parameters in the macro
definition. Otherwise, there shall be more arguments in the invocation than there are
parameters in the macro definition (excluding the ...). There shall exist a )
preprocessing token that terminates the invocation.

Ни в одной из имеющихся в моем архиве lib_xxx не обнаружил AT91C_BASE_AIC->AIC_IMR = 1 << AT91C_ID_PIOA;

Это не из lib_.

Очевидно, что в lib_xxx полно ошибок. А кто мешает их исправить и пользоваться дальше?

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

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

По мне структуры хороши хотя бы тем, что при отладке в Eclipse/Insight позволяют очень удобно смотреть содержимое регистров. Лучшего способа, чем добавить такую "сущность" в watch, я просто не знаю.

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

[zltigo]

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

Код

/******************************************************************************
** Function name:        install_irq
**
** Descriptions:        Install interrupt handler
** parameters:            Interrupt number, interrupt handler address,
**                        interrupt priority
** Returned value:        true or false, return false if IntNum is out of range
**
******************************************************************************/
DWORD install_irq( DWORD IntNumber, void *HandlerAddr, DWORD Priority )
{
    DWORD *vect_addr;
    DWORD *vect_prio;
      
    VICIntEnClr = 1 << IntNumber;    /* Disable Interrupt */
    if ( IntNumber >= VIC_SIZE )
    {
        return ( FALSE );
    }
    else
    {
        /* find first un-assigned VIC address for the handler */
        vect_addr = (DWORD *)(VIC_BASE_ADDR + VECT_ADDR_INDEX + IntNumber*4);
        vect_prio = (DWORD *)(VIC_BASE_ADDR + VECT_PRIO_INDEX + IntNumber*4);
        *vect_addr = (DWORD)HandlerAddr;    /* set interrupt vector */
        *vect_prio = Priority;
        VICIntEnable = 1 << IntNumber;    /* Enable Interrupt */
        return( TRUE );
    }
}

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

Код

int install_irq( int IntNumber, void *HandlerAddr, int Priority )
{
    VICIntEnClr = 1 << IntNumber;    /* Disable Interrupt */
    if ( IntNumber >= VIC_SIZE )
    {
        return ( FALSE );
    }
    else
    {      VICIntSelect &= (~(1<<IntNumber));     // Добавлено - Classifies as IRQ
    *(ulong *)(&VICVectAddr0 + IntNumber) = (ulong)HandlerAddr;    /* set interrupt vector */          
    *(ulong *)(&VICVectPriority0 + IntNumber) = Priority;          
    VICIntEnable = 1 << IntNumber;    /* Enable Interrupt */
    return( TRUE );
    }
}

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

Код

VICVectAddrX = (ulong)HandlerAddr;           
VICVectPriorityX = Priority;

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

[AHTOXA]

Что-то похожее на образец и отражающее суть железа:

Код

int install_irq( int IntNumber, void *HandlerAddr, int Priority )
{
    VICIntEnClr = 1 << IntNumber;    /* Disable Interrupt */
    if ( IntNumber >= VIC_SIZE )
    {
        return ( FALSE );
    }
    else
    ...

Я бы ещё строчку

Код

    VICIntEnClr = 1 << IntNumber;    /* Disable Interrupt */

перенёс после else

[zltigo]

По мне структуры хороши хотя бы тем, что при отладке в Eclipse/Insight позволяют очень удобно смотреть содержимое регистров.

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

Я бы ещё строчку

Код

    VICIntEnClr = 1 << IntNumber;    /* Disable Interrupt */

перенёс после else

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

[SergeiCh]

А смотрю на текст много, много, много больше нежели на окошки "watch

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

[zltigo]

Но мне структуры в этом не помеха...

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

[aaarrr]

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

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

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

[zltigo]

после простой доработки хидера напильником, и "PITC_PIMR = x".

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

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

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

[aaarrr]

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

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

[defunct]

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

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

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

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

PITC_PIMR = x".

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

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

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

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

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

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

EKLMN = x;
EPRST = y;

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

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

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

Эскизы прикрепленных изображений

 

[aaarrr]

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

hal.h:
#define pPITC AT91C_BASE_PITC
....

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

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

PITC_PIMR = x".

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

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

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

Код

int init_pitc(AT91PS_PITC pitc, ...)
{
    pitc->PIMR = x;
}

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

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

А где это я говорил про наглядность? Хотя влияет, конечно. Сравните
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'a, вы автоматом (смотря текст, а не watch) увидите какие еще регистры относятся VIC'у, без лазиния по ДШ и без, лишний раз, заглядывания в хидеры.

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

[zltigo]

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

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

преднамерено делается разгруппировка уже сгруппированных по смысловой нагрузке

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

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

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

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

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

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

Меньше.

Любой нормальный редактор умеет открывать структуры - и показывает их нутро в параллельном окошке типа object explorer etc.

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

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

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

[defunct]

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

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

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

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

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

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

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

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

[zltigo]

zltigo и aaarrr
Я там выше прикрепил рисунок.

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

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

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

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

[defunct]

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

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

*pAT91C_BASE_PITC->PITC_PIMR

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

[zltigo]

..и нет единственно правильного стиля.

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

[defunct]

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

Именно хорошее слово прогибать, а не отбрасывать как ересь все подряд и потом с Божьей помощью и с помощью ДШ писать с чистого листа.

[aaarrr]

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

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

в этой теме все крутится вокруг
lib_AT91 - которую некоторые рекомендуют выбросить и забыть как книжку Редькина

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

и вокруг "->" (тут уже imho безосновательно).

Как я уже писал, против структур периферии я ничего не имею, тем более что есть возможность маневра. У Atmel'а еще не самый худший вариант, если вспомнить, например, TI C28xx

[zltigo]

Драсти, а чем тогда я пользуюсь? ;>

Вы пользуетесь макросами типа
#define pNAME *(struct *)0xXXXXXXX
Это не указатель и, как уже писал, данное Вами имя в венгерском стиле pointerNAME - ошибочно.

...не отбрасывать как ересь все подряд и потом с Божьей помощью и с помощью ДШ писать с чистого листа.

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

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

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

[aaarrr]

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

Для этого нужно иметь некоторый опыт. А тут пытались ересь впарить невинным душам

[defunct]

Вы пользуетесь макросами типа
#define NAME *(struct *)0xXXXXXXX
Это не указатель.

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

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

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

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

[aaarrr]

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

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

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

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

[zltigo]

А тут пытались ересь впарить невинным душам

О чем и речь .

[defunct]

Нет, как не трудно догадаться, не про Редькина.

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

[zltigo]

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

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

[aaarrr]

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

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

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

[defunct]

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

это константный указатель.
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

[zltigo]

это константный указатель.

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

pBASE_NAME = x - не имеет смысла вообще.

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

это константный указатель.

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

pBASE_NAME = x - не имеет смысла вообще.

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

pPITC->PITC_PIMR = x;

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

[defunct]

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

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

По ней сразу видно как надо работать с DMA даже без вникания в ДШ.

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

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

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

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

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

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

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

pBASE_NAME = x - не имеет смысла вообще.

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

Код

pPITC->PITC_PIMR = x;

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

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

[aaarrr]

Вот мои слова:

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

Можно ничего не читая про DMA правильно с ним работать!

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

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

[defunct]

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

Можно ничего не читая про DMA правильно с ним работать!

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

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

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

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)

[zltigo]

Как так?

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

[defunct]

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

Бывает

[aaarrr]

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

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

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

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

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

Я так понимаю это дата всего пакета.

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

У меня:

Код

//* File Name           : lib_AT91SAM7X256.h
//* Object              : AT91SAM7X256 inlined functions
//* Generated           : AT91 SW Application Group  08/18/2006 (15:29:55)
...
//* CVS Reference       : /lib_pitc_6079A.h/1.2/Thu Nov  4 14:01:11 2004//

[defunct]

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

нет

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

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

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

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

[zltigo]

Бывает

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

[aaarrr]

нет

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

Код

//* Generated           : AT91 SW Application Group  05/20/2005 (16:22:29)

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

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

Код

//*----------------------------------------------------------------------------
//* \fn    AT91F_PDC_ReceiveFrame
//* \brief Close PDC: disable TX and RX reset transfer descriptors
//*----------------------------------------------------------------------------

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

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

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

[defunct]

Странно, в более ранней есть.
//* Generated : AT91 SW Application Group 05/20/2005 (16:22:29)

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

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

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

Код

    if (AT91F_PDC_IsRxEmpty(pPDC)) {
        //* Buffer and next buffer can be initialized
        AT91F_PDC_SetRx(pPDC, pBuffer, szBuffer);
        AT91F_PDC_SetNextRx(pPDC, pNextBuffer, szNextBuffer);
        return 2;
    }
    else if (AT91F_PDC_IsNextRxEmpty(pPDC)) {
        //* Only one buffer can be initialized
        AT91F_PDC_SetNextRx(pPDC, pBuffer, szBuffer);
        return 1;
    }
    else {
        //* All buffer are in use...
        return 0;
    }

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

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

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

[aaarrr]

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

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

Дык, мы ж о ReceiveFrame говорим

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

[defunct]

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

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

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

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

[sergeeff]

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

[aaarrr]

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

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

[SergeiCh]

Полезно ли embedded разработчику наличие lib_xxx или вы считаете, чтобы лучше ее и не было?

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

[asket]

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

[aaarrr]

Работаю в Crossworks, хотелось бы поработать с lib_1t91sam7xxx.h

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

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

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

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

[zltigo]

Тем, кто имеет слабость лениться думать самостоятельно, наличие этой библиотеки может навредить.

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

...проблем с multiple definition быть не должно.

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

[defunct]

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

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

При этом все запихивается а один файл....Чему это может научить?

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

как впрочем и выбрасывать неиспользованые функции, хоть они и с __inline

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

[aaarrr]

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

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

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

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

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


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

Код

//* File Name           : lib_AT91SAM7X256.h
//* Object              : AT91SAM7X256 inlined functions
//* Generated           : AT91 SW Application Group  09/12/2005 (15:39:14)
...
//* CVS Reference       : /lib_pitc_6079A.h/1.2/Thu Nov  4 14:01:11 2004//

...


/* *****************************************************************************
                SOFTWARE API FOR PITC
   ***************************************************************************** */
//*----------------------------------------------------------------------------
//* \fn    AT91F_PITInit
//* \brief System timer init : period in µsecond, system clock freq in MHz
//*----------------------------------------------------------------------------
__inline void AT91F_PITInit(
        AT91PS_PITC pPITC,
        unsigned int period,
        unsigned int pit_frequency)
{
    pPITC->PITC_PIMR = period? (period * pit_frequency + 8) >> 4 : 0; // +8 to avoid %10 and /10
    pPITC->PITC_PIMR |= AT91C_PITC_PITEN;    
}

[defunct]

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

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

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

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

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

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

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

[aaarrr]

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

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

It is
designed to offer maximum accuracy and efficient management, even for systems with long
response time.

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

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

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

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

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

2. Меня никто не заставляет его редактировать. (зачем его редактировать?)

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

[zltigo]

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

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

Качество кода я тоже демонстрировал - абсолютно ничего лишнего

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

Неужели удобнее цеплять с десяток хидеров, по одному для каждой мелочи типа SPI?

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

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

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

[defunct]

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

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

А какая проблема? Тем более,как человек широко использующий тот-же 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
никому не нужны.

[zltigo]

Вопросом на вопрос - нипойдет.
Хотя

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

что все компиляторы обязаны это делать?

нет.

[Сергей Борщ]

По мне структуры хороши хотя бы тем, что при отладке в Eclipse/Insight позволяют очень удобно смотреть содержимое регистров.

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

[injen-d]

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

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

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

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

[Сергей Борщ]

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

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

[SergeiCh]

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

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

[SergeiCh]

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