ATmega после x86

Сложилось так, что нужно мне (работа) программировать ATmega, а у меня опыт только на х86. Есть что-нибудь почитать на эту тему, чтобы выделить основные различия

 

Доки на атмегу, там все очень просто, есть пару книг о программировании МК AVR.

 

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

 

По АТмегам литературы, как уже сказано, море. Если деньги не напрягают (а раз работа, то, вероятно, нет), лучше не изобретать свой программатор, а взять готовый. Собсно, есть две больших группы: работающих через JTAG и через SPI. У любителей больше популярны вторые: там меньшее число ног, они поддерживаются даже самыми мелкими АТтиньками и т.д.; вероятно, ещё и дешевле. Но, насколько знаю, такие программаторы не имеют возможностей отладки: залил программу во флэш-память МК и смотри, что она делает. Что же касается JTAG (я только с таким дело имел), там есть возможность пошагового выполнения, контроля содержимого памяти и т.д. и т.п. Многие программаторы подключаются к ПК через LPT- или COM-порт, но есть и через USB. Кроме того, ничто не мешает взять адаптер USB-COM (мы в конторе именно такими и пользуемся; у себя дома я тоже через него подключаю программатор -- в т.ч. и для безопасности: если что-то там перемкнёт, то, в крайнем случае, спалит адаптер, а не мать).

Ну а вообще, если есть вопросы, лучше обращаться на сайты, специализирующиеся на МК. На WASMе людей, знакомых с этой тематикой, не так уж много: он всё ж на ПК в первую очередь ориентирован. Сходу могу назвать http://electronix.ru (возможно, самый крупный из всех русскоязычных форумов такой направленности), http://kazus.ru и http://radiokot.ru.

 

к списку ссылок добавлю самую неожиданную

http://avr.ru/

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

при выборе программатора и МК стоит обратить внимание - сможете ли вы работать с корпусом этого МК.

 

// сорри - дублирование

 

странно, что ещё никто не предложил easyelectronics.ru

 

qqwe

Я о ней даже не подозревал Собсно, никакой литературы мне и не потребовалось, только даташит на конкретный МК (АТмега-162) + описание системы команд. Это первый ассемблер учить сложновато, а когда 21-й...

 

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

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

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

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

 

qqwe

Это ещё от задачи зависит. Поморгать светодиодами -- да, а вот что-нибудь серьёзнее... Да и в любом случае, без знания ассемблера не может быть настоящего знания МК, ну а уж на чём писать программы -- это другой вопрос.

 

SII

Это еще откуда следует?

 

Оттуда, что: 1) ассемблер отражает систему команд вычислительной машины (микроконтроллера в данном случае), а без знания системы команд нет полного знания машины; 2) существует куча типично микроконтроллерных задач, которые в принципе невозможно решить на языке высокого уровня.

 

SII
1) Это не совсем правда. Зачем знать систему команд? Что это дает? Что есть "полное знание машины" и зачем оно нужно разработчику? Чем оно поможет в работе, ну например с элементарным UART?
2) Это совсем не правда.
Другое дела, что под некоторые мк просто НЕТ приличных реализаций ЯВУ. Тогда 2) - иногда правда.

 

Используем stm8. Довольны.

 

Ustus
Элементарные UART иногда встречаются по несколько штук работающих на мегабитной скорости, хорошо если удаётся задействовать DMA, а если его нет? Хорошо если у нас ARM, он все регистры одной командой сохранит, а если AVR? Там только код сохранения/восстановления регистров для обработчика прерывания несколько десятков команд и чуть ли не под сотню тактов, и что вы будете делать? Сдадитесь на 50000 прерываний в секунду?

 

Ustus
Глупость сказали, причём полную. Особенно по пункту 2. Например, без ассемблера невозможно выдерживать точные временнЫе интервалы между сигналами, выдаваемыми на ноги МК: никакой ЯВУ не предоставляет возможности посчитать времена с точностью до такта.

 

Black_mirror

И ставят в результате ARM со 128 килами флэша там, где благополучно отработала б и ATmega с 16-ю...

 

Black_mirror
Лучше в таком случае перейти на более быстрый контроллер. Или с DMA. Или еще чего-нибудь. В любом случае, ловля тактов - это жест отчаяния.
Что же касается регистров, то я вообще не понял, чем поможет асм?

SII

А это еще почему? Еще и поуниверсальнее, чем в асме в некоторых случаях

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

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

Только вот если вы лично никогда не испытывали такого кайфа:

Есть модуль строк где-то тыщи на две. Написан на асме. Не вами. Но вам пообещали, что все работает. Вы, конечно, не особо верите, но - план, проект, дедлайн, вобщем принимаем как есть.
И вдруг принимается волевой решение, которое уже давно зрело - размер пакета обмена (ну, в некоторой очень специфической самописной сети, не я выдумал, не спрашивайте зачем) меняется с двух байт на пять. Ну, перестали влазить, бывает.
И вот вы смотрите на эти две тысячи строк и вужосе понимаете, что ваш доблестный предшественник не только все на асме запузырил, он все это жоско к размеру два привязал, да еще и, пся крев, "заоптимизировал".
И тут два выхода. Первый: наплевать на все и писать заново, игнорируя истошные вопли начальства. Второй: править по живому, причем правка будет где-то процентов на 30-40 текста, и не факт, что не возникнут труднообнаружимые интерференции, на отлов которых уйдет еще больше времени... И еще слегка хочется застрелиться...

Так вот, если у вас такие случаи бывали, так я вам посочувствую. Если не было - приходите, когда будут, и я вам уже тогда посочувствую.

З.Ы. Уж простите за многабукав, просто больное место.
И я не против знать асмы - знайте на здоровье, среди них и довольно забавные случаются. Только не применяйте их, пожалуйста, лишний раз

 

SII

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

(кроме того, немного больше ресурсов позволит использовать миниось, пример, программирование с которой, а особенно поддержку и расширение, сделает гораздо приятнее и мягче)

Ustus

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

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

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

 

qqwe

Это одна из причин, почему в будущих изделиях отказываемся от АТмег в пользу СТМ32 или другого какого АРМа. Ну а вторая -- исчерпание ресурсов уже применяемой АТмеги-162 (16 кил флэша забиты под завязку -- свободно меньше 200 байтов, и это на асме, а не на ЯВУ, причём с нарушениями моих же собственных правил насчёт чёткого деления на модули: иначе, боюсь, не влезло бы вообще; правда, из ~6000 строк исходника примерно 1000 -- всякие там комментарии и т.п.). Можно, конечно, одну Мегу поменять на другую, более жирную, но это лишь временное решение, не дающее принципиальных преимуществ. Кроме того, ещё по ногам ограничены: сейчас используется 33 (у 162-й их 35 всего), а значит, сразу отпадают любые МК с меньшим их числом, что сужает выбор...

Ну, то, что часто называют ОСРВ, лично я постыдился б назвать осью вообще -- так, примитивная переключалка потоков. Такое у меня и самого есть для АРМа, хотя стремлюсь в конечном счёте к полноценной системе, только с возможностями тонкой настройки под конкретное железо и сферу применения (что не нужно, не включается в создаваемый образ системы, чтоб не занимало лишнее место и не добавляло тормозов, не говоря уж о том, что не каждая железяка имеет, например, MMU или MPU). Сделано пока мало что, но это "мало" уже применяется во внутренних проектах.