С чего начать изучение PIC-контроллеров новичку?

HOWK
- Может быть у кодирования на ассемблере есть какие-то недостатки, кроме тупых, ленивых и несерьезных программистов?

caddr: Может быть у кодирования на ассемблере есть какие-то недостатки, кроме тупых, ленивых и несерьезных программистов?

Попытаюсь подобрать аналогию. Какие недостатки у дискретного транзистора по сравнению с интегральной микросхемой? Микросхема по своей сути содержит те же транзисторы.

Если вы раньше никогда не писали программы на каких-либо языках среднего и высокого уровней, но хорошо знакомы с разработкой цифровых схем на "рассыпухе", ваш выбор однозначен - ассемблер. Команд мало, изучить просто. "Въедете" быстро и безболезненно. Зато писать нудно и муторно.

Если никогда не занимались проектированием схем на "логике" низкой степени интеграции (типа 155, 561 и пр.), но зато свободно пишете программы для "больших" компьютеров на Си, ваш выбор тоже однозначен - компиляторы Си для МК. Просто пересядете с иномарки на "запорожец".

Еще аналогия. Ассемблер - это буквенный алфавит. Изучите буквы - научитесь писать слова и предложения. Си - китайские иероглифы. А это уже целая философия.

Когда-то, когда ещё учился в институте читал статистику по которой средняя скорость написания программы для обычного программиста составляет 25 отлаженных программных строк в день. Причём независимо от языка программирования. Отсюда вытекает, что при использовании ЯВУ эффективность выше. Но у ассемблера есть свои преимущества.

SAK: Отсюда вытекает, что при использовании ЯВУ эффективность выше.
Однозначно!.. Но! Если радиолюбительские цели - две, три простенькие программы в год, нужна ли эффективность? Платы, например, гораздо эффективнее изготавливать и собирать на специализированном оборудовании, а мы тут "мыкаемся" с фотошаблонами, фоторезистами, жутко неэффективно тычем в детали паяльником. Я вот, на ассемблере худо-бедно научился программы писать, а Си так и не освоил, хотя принимался неоднократно. А потом, когда нет практики, как ни крути, все забывается. В ассемблере важен принципиальный подход, его сложно забыть, ну а мнемонику команды - другой забудешь, можно и в шпаргалку глянуть. Это алфавит, где буквы можно комбинировать, руководствуясь только логикой и здравым смыслом.
ЯВУ - языки. Просто так буквы не скомбинируешь. Надо заучивать и помнить целые слова, да еще и громадную кучу различных строгих грамматических и синтактических правил, без знания которых хрен чего напишешь, если забыл.
Конечно, я рассуждаю, как дилетант, которым по сути и являюсь в данной теме, но и вопрос, заданный в заголовке темы, думаю, задан без расчета на желание фундаментального и профессионального изучения.

2 djelektronik
Если Вы на спектруме на бейсике писали, то увы...
Имея всего 48 кБ памяти невозможно написать ничего толкового на оном.
Ведь на спектруме борьба шла за каждый бит. Для этого нужно было глубокое понимание
как архитектуры компьютера, так и умелое использование возможностей процессора.
Ведущие программисты мира писали игры для спектрума, да еще какие.
Составление алгоритма - сущий кошмар для современных " программистов ", а без
алгоритма не будет толковой программы. Да что я прописные истины провозглашаю.
С ассемблера перейти на любой язык высокого уровня не представляет труда, а вот
наоборот - неразрешимая проблема. Жесткая логика, привитая программировонием на
ассемблере дисциплинирует при программировании на других языках. Это проверено
уже на многих студентах за 8 лет. Я уже говорил, программировать можете на чем
угодно и как угодно, но в конечном итоге вернетесь к упоминавшимся строчкам.
Это в том случае, когда дойдете до определенного уровня программирования, а дальше - тупик.
( просто - напросто не будет хватать памяти или не удовлетворит быстродействие ).

HOWK
в наше время можно взять более быстродействующий мк с бОльшей памятью при незначительной разнице в цене
сейчас уже не время з80 и 48к памяти

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

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

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

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

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

вот это все и нужно нам - простым радиолюбителям
а профи не нуждаются в выборе чего-либо

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

предлогаю сторонникам асм посмотреть http://www.mcselec.com/index.php?option=com_content&task=category&sectio...
все написано на языке высокого уровня

я вообще не вижу щас авр проектов на асм

Zandy
на си тебе не надо думать по большему счету
вот тебе простой пример

на юарт приходит 1 байт в виде аски
тебе надо выбрать 1 из 4х функций для выполнения каких-либо операций
функции a, b, c,d
я напишу этот код за 2-3 минуты без отладки

#unclude <stdlib.h>

viod main(void){

.... конфиг периферии, юарт...
while(1){
switch (getchar()){
case 'a': a();
break;
case 'b': b();
break;
case 'c': c();
break;
case 'd': d();
default: sendstring("press a b c or d");
}
}

теперь сколько времени ты будеш писать это на асм?
getchart и sendstring стандартные функции для работы с юарт

Добавлю, что в подавляющем большинстве ВУЗов курс "введение в специальность" для будущих профессиональных программистов строится с использованием какого-либо ЯВУ, а вовсе не ассемблера. Видимо потому, что понять ключевые концепции (абстракция кода, абстракция данных, модульность, состояние, и т.д.) при таком подходе гораздо легче.

Один из лучших учебников -- "Structure and Interpretation of Computer Programs" (SICP), так и вовсе использует ЯП Scheme (Схема). Схема -- более высокоуровневый язык по сравнению с Си, Паскалем или Бейсиком. Список зарубежных ВУЗов, вводный курс которых построен на базе этой книги, говорит о многом:
http://mitpress.mit.edu/sicp/adopt-list.html

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

HOWK: Составление алгоритма - сущий кошмар для современных " программистов "
Я уже не один раз высказывал своё отношение к составлению алгоритма в виде прямоугольничков и ромбиков. Это другой язык. Это применяют для обучения алгоритмизации, но никак для реального программирования. Это как если для перевода документа на немецкий язык его сначала надо перевести на английский и потом уже с него на немецкий. Попробуйте составить алгоритм для программы с использованием классов, ну например на Delphi или C++, или даже под WinAPI построенного по принципу call-back функций. Программа в этих случаях представляет из себя набор никак явно не связанных между собой кусков которые вызываются из кода написанного чаще всего не вами и в общем случае его внутреннее построение неизвестно.
В случае микроконтроллеров всё немного проще, однако и здесь есть особенности которые непросто описать алгоритмическим языком, но легко описать на ассемлере или хотя бы на Си, например, асинхронная работа по прерываниям.

SAK
- Как Вы наверное знаете, "алгоритмы" для больших программ все-таки составляют -- но, обычно, на несколько более высоком уровне абстракции, нежели "если переменная X = 2 то ... иначе ..."
Хорошим примером средства проектирования такого рода может быть распространенный нынче UML.

Я имел ввиду, что любая программа является алгоритмом и её написание и есть составление алгоритма как такового. Поэтому мне непонатны утверждениея, что программист пишущий программу не может составить алгоритм её работы, а ведь иненно это он и делает. И не обязан он сначала составлять алгоритм на одном языке, что бы потом переписывать его на другом.
caddr: "алгоритмы" для больших программ все-таки составляют
Конечно составляют! Я и сам так делаю, только сразу на том же языке на котором и будет вся программа. Вначале пишется основная часть без детализации отдельных действий которые выносятся в отдельные функции и затем уже решаются по мере необходимости. Есть такое правило: любая функционально законченная часть программы должна умещаться на экране. Тогда будет трудно запутаться и нагородить ошибок. Это не означает что из правил не бывает исключений.