Atmel Studio + ASF + SAM4S, Помогите начать Опции

[Haamu]

В Atmel Studio есть такая чудесная штука под названием Atmel Software Framework (ASF) с кучей прекрасных примеров. Проблема вся в том, что все эти примеры идут под определенные отладочные платы. Да и вообще, как то всё запутано в этом ASF. В интенете как то скудновато информации на эту тему.

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

Существует ли в природе какая-то альтернатива ASF, что нибудь вроде как SPL (Standard Peripherals Library) для STM'ов?

[DpInRock]

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

И вместо Атмел Студио я бы бросил взгляд в сторону IAR или Keil.

[Alex A. Mihaylov]

какая-то альтернатива ASF, что нибудь вроде как SPL (Standard Peripherals Library) для STM'ов?

А в чем проблема? Там есть замечательный USER BOARD - потом говоришь камень в основе и все. Тебе остается в хедере подправить настройки тактирования для работы. А всеми прелестями ASF можешь пользоваться.

Что до Keil (IHMO: боже упаси) или IAR (IHMO: больше с лицензией воюешь, чем программируешь. А ценник совершенно неадекватный.) то не рекомендую. AVR и ARM gcc в основе AVRStudio - штука достаточная для работы и в то же самое время весьма не хилая. А gdb в него так здорово интегрирован, что последний козырь IAR'а оказывается побит. У него, правда, еща распоследний есть - макроязык для стимуляции входных данных - но это совсем на любителя.

Но в целом - лучшая библиотека это документация на чип. Тут я с коллегой согласен.

Сообщение отредактировал Alex A. Mihaylov - Mar 13 2014, 00:27

[Haamu]

Но в целом - лучшая библиотека это документация на чип. Тут я с коллегой согласен.

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

IAR или Keil... Как то уж очень ценник у них пугающий. Пока обхожусь функционалом бесплатных IDE.

[DpInRock]

Но все-же наличие библиотеки очень сокращает процесс написания программы.

Судя по сообщениям форума - это далеко не так.

[Golikov A.]

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

так что сам акт писания действительно становиться меньше....

[Alex A. Mihaylov]

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

Не совсем. IHMO лучше тупежка при запуске, чем она же при сопровождении. А профи ВСЕГДА пишет так, чтоб можно было без проблем сопровождать код. И уж подавно не надо молить о поддержки, а после забивать костыли. Надо читать мануалы до полного просветления. И уж подавно реагировать на негативные отзывы - это просто кормить тролей.

К теме форума: ASF хорош, но не догма. В частности I2C device там сделан просто отвратительно. А вот USB device на порядок лучше STM'овского.

Впрочем, Atmel любят именно за то, что с их чипами можно работать и по голому железу (опять камень в сторону огорода ST).

[Haamu]

Не совсем. IHMO лучше тупежка при запуске, чем она же при сопровождении.

Полностью с Вами согласен.

Надо читать мануалы до полного просветления.

Тоже верно. Но вот что делать, если мануалы не особо информативны. У тех же ST SPL на столько просто устроена. Для каждой периферии по одному исходнику с заголовочником, в исходниках для каждой функции описание дано, что никакой мануал и не нужен становится. А в ASF всё как-то уж очень запутано. Тут всё дело в универсальности, одна библиотека на все случаи жизни.

Впрочем, Atmel любят именно за то, что с их чипами можно работать и по голому железу (опять камень в сторону огорода ST).

STM ни чуть не уступает в этом плане. CMSIS то для всех одинакова.

К теме форума: ASF хорош, но не догма.

А есть альтернатива? Всмысле другая библиотека какая?

[Golikov A.]

в исходниках для каждой функции описание дано, что никакой мануал и не нужен становится

вот в этом месте обычно больнее всего и прилетает...

ИМХО надо писать свою библиотеку (или использовать свою корпоративную) если сидишь плотно на проце, не обязательно писать с нуля, можно хорошо проверять и править чужие исходники, но главное не использовать в слепую. В целом у всего что идет бесплатно в начале так и написано, используй на свой страх и риск, это только демонстрация и примеры.

[Alex A. Mihaylov]

Тоже верно. Но вот что делать, если мануалы не особо информативны. У тех же ST SPL на столько просто устроена. Для каждой периферии по одному исходнику с заголовочником, в исходниках для каждой функции описание дано, что никакой мануал и не нужен становится. А в ASF всё как-то уж очень запутано. Тут всё дело в универсальности, одна библиотека на все случаи жизни.

Ну... У ASF есть отличная документация на сайте. Например, вот страница про I2C-slave для xMega (Хм... Мне показалось или этот кусок переписан и стал несравнимо лучше). Да и сама Atmel Studio открывает как раз нужную станицу.

STM ни чуть не уступает в этом плане. CMSIS то для всех одинакова.

Ни за что! Да, конечно, CMSIS одна, ибо она описывает ARMовское ядро. А вот набор регистров перефирии разный. Как и их содержание.

По мне ST чем-то похож на Китайский автомобиль. Каждая интерфейсная часть - прямо чудо. И все предусмотрено, и кнопочек-ручечек вагон, сидухи с шикарной подержкой, двигло отлично, коробка - класс, мафон с офигенным экраном просто чудо. Но в целом не чип, а сборище понадерганных кусков (сидухи примялись и отвалились, двигла не хватает для коробки, мафон не воспроизводит MP3, а кнопочками-ручечками вслепую пользоваться не получается - слишком плотно, соседнюю зацепляешь). Atmel в этом плане прямо красная Итальянская машинка с лошадкой на капоте. В том смысле, что дизайн не броский, сидухи без изысков, мафона вообще нет да еще и задний привод! Но раз прокатившись полюбишь навсегда. Ибо все составные части четко выверены и подогнаны. Все для твоего удобства.

Впрочем, каждый выбирает для себя... Возможно, я слишком критичен.

А есть альтернатива? Всмысле другая библиотека какая?

Ну так сказали же - есть. Документация на процессор. И уж поверьте мне, применительно к Atmel это не отсыл в лес, а реально дельный совет. Попробуйте. Вам обязательно понравится.

Сообщение отредактировал Alex A. Mihaylov - Mar 14 2014, 02:06

[Haamu]

По мне ST чем-то похож на Китайский автомобиль.
...
Atmel в этом плане прямо красная Итальянская машинка с лошадкой на капоте.

Если честно, пока не увидел такую разницу. Наверно я еще до конца не распробывал ни первый, ни второй.
Спасибо за советы, буду разбираться.

[RabidRabbit]

А я вот брошу "фи" в сторону Atmel - в SAM D у них есть PTC (Peripheral Touch Controller), а вот описание регистров положить в даташит "забыли" - пользуйтесь QTouch library. Или может вообще нет там никакого PTC, а всё софтом реализовано

[Alex A. Mihaylov]

А я вот брошу "фи" в сторону Atmel

Есть такая буква... Безгрешным был только один человек, и того через 33 года распяли. Могу добавить в список камней TWI на SAM'ах - редкостная гадость.

[Haamu]

Всеже предлогаю вернуться к теме. Есть ли какая альтернатива ASF? Именно библиотека для работы с перефирией. Чем-то же люди пользовались до появления ASF? Чем больше разбираюсь с ASF, тем сильнее убеждаюсь, на сколько всё там запутано и усложнено. Взять тот же SPI. Для его инициализации надо вызвать с десяток функций, каждая из которых устанавливает по одному биту в регистр управления. Не проще сделать как у STM, заполнить структуру и проинициализировать всё одной функцией? В то же время инициализацию USART почему-то сделали через структуру. Такое ощущение складывается, что ASF писала не одна команда программистов, а будто куски нахватали из разных мест и собрали в кучу.

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

Не проще сделать как у STM, заполнить структуру и проинициализировать всё одной функцией?

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

[Alex A. Mihaylov]

Такое ощущение складывается, что ASF писала не одна команда программистов, а будто куски нахватали из разных мест и собрали в кучу.

Категорически неправильное ощущение. Все дело в том, что ASF API работает на всех камнях от Atmel'а (AVR, AVR32, xMega, Cortex'ы). Как следствие универсальности усложненность и избыточность. Поэтому подходит для быстрого прототипирования, но не желательно (не невозможно, а нежелательно) применять его в конечном изделии. Но тенденция в Ваших вопросах мне нравится. Еще немного и Вы поймете, что ASF или STM Lib всего лишь средство прототипирования.

Что до кокретно взятого SPI. Возъмем его API. Что мы имеем?

Код

spi_set_baudrate_div(...)
spi_set_bits_per_transfer(...)
spi_set_clock_phase(...)
spi_set_clock_polarity(...)
spi_enable_clock(...)

Вы видите более удобной запись в стиле ST:

Код

struct {
    .baud = ...
    .bits = ....
    .CPA = ....
    .CPH = ....
} spi_master;

eneble_periph_clock(...)
spi_deinit();
spi_init(spi_master):

Ну не знаю... Я даже не буду говорить о том, что память под структуру выделяется либо глобально (и забирает ее у проекта) либо в стеке и тем самым заставляя его расти. Но он просто выглядит куда более громозко и неиформативно. Конечно, если знать что такое SPI, какие главные параметры ему надо выставить. Но ведь даже ST не снимает этого ограничения. Я в свое время долго думал над этой их структурой. Половина структуры относится к SPI, половина к I2S при этом что к чему неочевидно. А еще и есть поля, относящиеся и к одному и к другому. А хваленые коментарии в коде не помогают чуть меньше чем совсем. Только чтение datasheet и понимание текста функции init(). Здесь (IHMO) все гораздо прозрачнее.
Да и вообще, но по моим ощущениям именно это и есть крайне неудобная часть в STM библиотеке. Хуже только USB стек с бесконечными

Код

unsigned char devDesc[] = {
    0xFA, 0xFB,  // wVendorId
    0x00, 0x01,  // wProductId
    ....
}

Только за это расстрелял бы на месте.

Сообщение отредактировал Alex A. Mihaylov - Mar 20 2014, 00:32

[DpInRock]

Блин, пришлось воспользоваться процессором ATSAM3A (из-за USB host), к которому нет обычных примеров от Атмела, а есть только ASF.

Вот мне было бы интересно просверлить голову тому чуваку, который эту ASF затеял и посмотреть что там есть.
Хоть прям STM32 бери...

[dimka76]

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

Мне тоже ))).
Свалили все в одну кучу.
До этого у них был AT91SoftwarePakage (или как-то так) все гораздо прозрачнее было.