Что нужно иметь и знать дабы прогарммировать PIC и AVR?

[lsvjy]

а вот какие учебники по асамблеру посоветуете?

[DX168B]

Я начинал с нашей местной обучалки, за тем пользовался простыми справочниками по АСМу.
Где-то сайт даже был, не помню ссылку. Из орудий у меня AVR Studio, WinAVR и программатор LPT 5-ти проводковый - UniProf. Работаю так уже полтора года, сделал кучу девайсов на МК.
Практически всё освоил самостоятельно. На счёт Cи - я его немного знал и до этого, но всё равно программирую МК на АСМе. Вот уже программы на ПК пишу на С++. Порты LPT ниразу не спалил, хотя к этому порту соединялись мегаизвратные, с точки зрения схемотехники, устройства. (паянные навесным методом в виду нехватки материала)

[lsvjy]

и программатор LPT 5-ти проводковый

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

[Murav]

Дискусия веселая
самое первое и главное это Ассемблер, нельзя сразу скакать на языки высокого уровня.
с Ассемблера начинается понимание как вообще ЭТА ШТУКОВИНА устроена,

ИМХО, начинать изучение МК лучше с изучения программирования на компьютере - там гораздо легче отлаживать программу. Так же там есть готоТак же советую начинать с языков высокого уровня(лучше всего - C, C++ или в крайнем случае Pascal) - они гораздо ближе к естественному языку. В качестве среды разработки что-нибудь типа Borland C++ Builder или аналогичной IDE(что там с ними сейчас - не знаю).
Использовать Basic для обучения программированию крайне не советую - слишком уж он сильно отличается от используемых сейчас языков.

Лично я выбрал для себя такой набор инструментов:
Управление проектом - Redmine.
Компилятор C, как уже говорил, = GCC (WinAVR).
Управление версиями - Subversion.
Документирование проекта - Doxygen.
Статический анализ кода - Splint.
Форматирование исходного кода - Indent.
Сборка проекта - GNU Make.
Тестирование - Unity.
Автогенерация мок-объектов - Cmock.
Вроде из основных ничего не забыл. Да, сам проект делаю в среде Dev-C++.

Для начала будет достаточно только IDE(для AVR обычно используют - AVR Studio+WinAVR, CVAVR и IAR), а всякое управление проектом(оно вообще нужно при разработке одним человеком?), версиями(это может пригодиться только в больших проектах), анализ кода и т.д. вряд ли тут же понадобятся новичку.

[DX168B]

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

Uni-Prof работает и с COM портами, схема тоже простая.
Только порт не виртуальным должен быть. То есть всякие переходники, типа USB-COM он не любит.

[Goldsmith]

Для начала будет достаточно только IDE(для AVR обычно используют - AVR Studio+WinAVR, CVAVR и IAR)

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

а всякое управление проектом(оно вообще нужно при разработке одним человеком?)

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

версиями(это может пригодиться только в больших проектах)

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

анализ кода и т.д. вряд ли тут же понадобятся новичку.

Если новичок согласен остановиться на уровне мигалок-свистелок, то можно обойтись без инструментов. А если есть желание стать профи, лучше сразу учиться правильному процессу.

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

[Jack_A]

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

Я , наверное, ретроград и потому не увлекаюсь модными тенденциями. Память стариковская уже не очень, но тем не менее пока не испытываю напряга с версиями. Новую версию держу в новой папке, в начале подробно комментирую , чем она отличается от старой, старый вариант в новой версии держу закомментированным, а если уж понадобятся подробности, старый добрый MultiEdit разобъяснит мне до запятой различия. Ну и конечно, веду рабочую тетрадь, но по старинному, на 96 листах в клеточку.
Кто как привык. Конечно, если бы у меня весь этот "зоопарк" был, пробовал бы осваивать, мож что и применил бы, а так -- искать не чувствую нужды.
От уровня "мигалок и свистелок" ушел давно и далеко...

[Murav]

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

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

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

Обычно в проектах, которые делает один человек не так много всего, чтобы это нельзя было запомнить. А если что-то(например, то что в данном месте ошибки нет или какие-то неочевидные из названия особенности функции) запомнить не получается, то оно записывается в комментарии рядом с кодом к которому это относится.
Мне ещё не разу не приходилось использовать специальные программы для управления проектом, хотя я иногда пишу весьма немелкие программы.

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

Что такое система контроля версий я знаю и даже время от времени её использую. Только в маленьких(а большие без необходимых умений написать невозможно) программах с неё толку ноль - создаётся 2-3 ревизии и проект заканчивается.

Если новичок согласен остановиться на уровне мигалок-свистелок, то можно обойтись без инструментов. А если есть желание стать профи, лучше сразу учиться правильному процессу.

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

[Мурик]

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

Да неужели?
Хотя может и отличается.... в лучшую сторону!

Бейсик это такой же язык как и все остальные и правила написания программ такие же, но в тоже время, он проще в понимании.
Если одну и туже программу можно написать на бейсике и на Си, но при этом, используя бейсик, потратить меньше сил, то в чем преимущество Си? (это только пример)
Как говорили в одной известно рекламе - "Если нет разницы, то зачем платить бельше"?

[Goldsmith]

Мне ещё не разу не приходилось использовать специальные программы для управления проектом, хотя я иногда пишу весьма немелкие программы.

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

Что такое система контроля версий я знаю и даже время от времени её использую. Только в маленьких(а большие без необходимых умений написать невозможно) программах с неё толку ноль - создаётся 2-3 ревизии и проект заканчивается.

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

В мире разработки софта для "больших систем" разработаны технологии для получения надежного, хорошо протестированного кода, и они постепенно (хоть и очень медленно) переносятся на программирование микроконтроллеров. В частности, одна из таких технологий (TDD, Test-Driven Design) вплотную завязана на систему управления версиями. Кстати, после каждого рефакторинга тоже очень рекомендуется commit. А в случае обнаружения серьезной ошибки в репозитории создается специальная ветка для ее исправления, которая потом сливается с проектом. Поэтому системой управления версиями нельзя пользоваться "время от времени" - она должна постоянно быть под рукой, как паяльник и осциллограф.

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

И какой толк от этих инструментов в небольших программах?

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

А при необходимости ничего не мешает поставить и разобраться с нужными инструментами.

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

Вы совершенно справедливо говорите:

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

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

[Goldsmith]

Я , наверное, ретроград и потому не увлекаюсь модными тенденциями.
...
Новую версию держу в новой папке, в начале подробно комментирую , чем она отличается от старой, старый вариант в новой версии держу закомментированным, а если уж понадобятся подробности, старый добрый MultiEdit разобъяснит мне до запятой различия. Ну и конечно, веду рабочую тетрадь, но по старинному, на 96 листах в клеточку.

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

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

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

[Goldsmith]

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

Да неужели?
Хотя может и отличается.... в лучшую сторону!

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

Солидарен с Murav. Немаловажно, что для языка C есть весьма строгие стандарты ANSI, и приличные компиляторы их поддерживают. Это обеспечивает хорошую совместимость и переносимость программ. Например, изрядную часть кода для микроконтроллера можно протестировать и отладить на PC, даже не загружая в контроллер.

Аналогичные стандарты на Basic если и есть, то, во-первых, не попадались мне на глаза, а во-вторых, похоже, также не попадались на глаза разработчикам компиляторов, что еще хуже. Уж больно несовместимы разные реализации этого языка.

Ну и в довершение - пара цитат из классика программирования Эдсгера Дейкстры:

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

("Ответы на вопросы студентов отделения программного обеспечения.")

Практически невозможно научить хорошо программировать студентов, ориентированных первоначально на БЕЙСИК: как потенциальные программисты они умственно оболванены без надежды на исцеление.

("Как быть, если правда колет глаза.")

К мнению этого человека определенно следует прислушаться (не сочтите за холивар).

[Murav]

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

Для программ типа "помигать парой светодиодов при нажатии определённой кнопки" - на бейсике проще, но вот более-менее серьёзные программы на C писать заметно проще.
Например в бейсике нельзя объявлять и инициализовывать переменную одновременно, нет операторов типа += , в одной строке производить несколько операций над переменными(впрочем в части реализаций бейсика это ограничение убрано), а так же изменять одним оператором(то есть строкой с одной ; ) несколько переменных. В маленьких программах эти ограничения почти не заметны, но вот в более-менее больших уже очень сильно тормозят написание кода.

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

А для чего оно при этом будет полезно?

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

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

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

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

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

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

В частности, одна из таких технологий (TDD, Test-Driven Design) вплотную завязана на систему управления версиями.

Это всё явно относится к команде программистов.

Есть популярное мнение, что размер - не главное, и в данном случае с ним трудно не согласиться.

И всё-таки какой от них толк?

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

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

[Мурик]

Например, изрядную часть кода для микроконтроллера можно протестировать и отладить на PC

Да ну.
Как будете тестировать работу с на компе с регистрами МК и внешними девайсами?

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

Можно.
Объявление переменной с именем Var, типа Long и записью в нее числа 2

Код: Выделить всё

Var.l = 2

нет операторов типа +=

А зачем, если можно поступить так

Код: Выделить всё

Var.l + 2

Как видите, тут объявляется переменная типа Long и сразу выполняется команда, аналогичная += из Си.

в одной строке производить несколько операций над переменными

Можно.

Код: Выделить всё

Var.l + 2 : Var * 4 : x+10 : z = x - 2

[Goldsmith]

Например, изрядную часть кода для микроконтроллера можно протестировать и отладить на PC

Да ну.
Как будете тестировать работу с на компе с регистрами МК и внешними девайсами?

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

Во-первых, вводится уровень абстракции оборудования (HAL, Hardware Abstraction Layer). В него выносятся все аппаратно-зависимые части программы. При грамотном проектировании они получаются очень небольшими. Кстати, концепции HAL замствованы из архитектуры операционных систем/ Например, HAL есть в семействе Windows NT.

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

После этого логика программы тестируется на PC по-взрослому, включая протоколы взаимодействия с аппаратурой. И на сладкое остается лишь аккуратненько реализовать HAL на контроллере, что не представляет проблемы ввиду простоты.

Кстати, именно поэтому я выбрал в качестве основного компилятора GCC для AVR, хотя IAR дает код получше. Зато GCC реализован практически на всех мыслимых платформах, а я предпочитаю чуть менее быстрые и компактные, но зато надежные программы.

Если интересно, такой подход описан в книге: James W. Grenning, "Test Driven Development for Embedded C".

[Murav]

Да ну.
Как будете тестировать работу с на компе с регистрами МК и внешними девайсами?

Работу с периферией естественно оттестировать не получится(хотя её вполне можно эмулировать), а вот алгоритмы - вполне.

Можно.
Объявление переменной с именем Var, типа Long и записью в нее числа 2

Это разве заменяет Dim? А так же в каких реализациях бейсика такое есть?

Можно.
Код:
Var.l + 2 : Var * 4 : x+10 : z = x - 2

Это, насколько я понял, всего лишь несколько операторов в одной строке, то есть тоже самое,что

Код: Выделить всё

Var+=2;Var*=4;x+=10;x=x-2;

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

Код: Выделить всё

if (data[addr++]=='t' && data[addr++]=='e' && data[addr++]=='s' && data[addr++]=='t') P
***
} else {
ShowError("error at %u character",addr-1);
}

И, кстати, указатели в бейсике есть?

[Goldsmith]

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

А для чего оно при этом будет полезно?

Капитан Очевидность подсказывает, что управление проектом полезно для управления проектом. А конкретно: обсуждение проекта с заказчиком, сбор требований и пожеланий, ранжирование их по степени важности, планирование задач, ведение Wiki по проекту, регистрация багов и отслеживание их исправлений, форум поддержки пользователей продукта и т.д. Конечно, все это можно пытаться держать в голове (лично в моей это все точно не умещается, неоднократно проверено) или записывать в тетрадке, но я предпочитаю напрягать компьютер. Не для одного пасьянса же он куплен.

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

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

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

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

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

[Goldsmith]

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

Эх, вашими бы устами мед пить... Заказчик нынче ушлый пошел. Ему и Zigbee подавай, и встроенный в прибор WWW-сервер, и массу прочих вкусностей, а все это требует массу кода. Да, где-нибудь на задворках проекта вполне уживаются Mega8, а то и вовсе какой-нибудь Tiny. Управляют себе моторчиком или еще каким незатейливым девайсом. Но как самостоятельные девайсы сбыть их проблематично. По крайней мере, мне не удается.

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

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

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

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

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

[Мурик]

Это разве заменяет Dim?

Диалекты разные бывают.

А так же в каких реализациях бейсика такое есть?

Скажем, в этом.

И, кстати, указатели в бейсике есть?

Неа, чукча с памятью работать не умеет.
Конечно же есть.

[Goldsmith]

В частности, одна из таких технологий (TDD, Test-Driven Design) вплотную завязана на систему управления версиями.

Это всё явно относится к команде программистов.

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

И всё-таки какой от них толк?

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

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

Опять же, совсем не факт. Посмотрите, например, сколько в datasheet на ту же Mega занимает полное описание системы команд. А теперь положите рядом, скажем, текст стандарта
ISO/IEC 9899:1999 по языку C (554 страницы). Ведь нельзя же всерьез утверждать, что человек, не удосужившийся даже проштудировать стандарт, умеет хорошо программировать на языке C.