Шпак Ю.А. Программирование на языке C для AVR и PIC микроконтроллеров
Вот что я нарыл. Собственно, других книг по GCC я больше и не встречал. Одно время был классный мануал в виде chm файла, но потом он куда то делся и больше я его не видел. Так что качайте что есть 🙂 Тут вначале рассмотрен сам язык Си, хуже конечно чем в оригинале от Кернигана и Ритчи, но зато обьемом поменьше. А дальше идет описание языка Си уже с упором на микроконтроллеры. Довольно кратко, но есть примеры, а это главное. Для PIC описывается компилятор CCS-PICC, а для AVR разобран GCC WinAVR.
Особо меня тут порадовал справочник в конце книги, где кратко расписаны все функции стандартной поставки CCS-PICC и GCC WinAVR с примерами. В общем, выбора у вас нет, раз ленитесь писать на ассемблере, то придется разбираться вот по этой книжке 🙂
Спасибо. Вы потрясающие! Всего за месяц мы собрали нужную сумму в 500000 на хоккейную коробку для детского дома Аистенок. Из которых 125000+ было от вас, читателей EasyElectronics. Были даже переводы на 25000+ и просто поток платежей на 251 рубль. Это невероятно круто. Сейчас идет заключение договора и подготовка к строительству!
А я встрял на три года, как минимум, ежемесячной пахоты над статьями :)))))))))))) Спасибо вам за такой мощный пинок.
23 thoughts on “Шпак Ю.А. Программирование на языке C для AVR и PIC микроконтроллеров”
я во всех ваших спорах «си против асма» уже участвовать не хочу )
но может кому-нить си на 4к доступной памяти и пригодится… зы! хотя я лично, когда юзал отладочную платку с армом9 и линухой на нём, использовал этот самый си там аж на процентов 90 ) ззы! с програмерством на вижеле, гэцэцэ и всех средах, вплоть до эклипса, знаком )
ну надеюсь, что я не догматик…
я прекрасно разбираюсь даже в тех вещах, где удобнее использовать билдер вместе вижела, асм вместо си и даже лисп вместо всех других языков, вместе взятых ) си для армов — это компромисс цены, времени и производительности. всё как в физике — выигрыш в усилении компенсируется устойчивостью и всё такое…
Ну тут спорить особо не стоит, конечно. Но как мне кажется — основное преимущество С — это переносимость программ на разные контроллеры — только HAL заменить и можно спокойно использовать программу несколько раз, а не изобретать велосипед заново.
Алексей
Переносимость — понятие растяжимое… (В принципе, и из любого приемника, даже детекторного, можно сделать телевизор, добавив недостающие детали).
Перенести программу, например, c Меги 16 на 32 — и в ассемблере не проблема.
А, к примеру, с АРМ на Тини — никакой С не поможет.
Ну, а с определенными оговорками — любой язык высокого уровня обладает переносимостью, если не использовать абсолютные адреса. Но только поклонники третьей буквы латинского алфавита упорно твердят об этом, доводя, в общем — то, неплохую идею, до абсурда. В то же время даже перенести программу для одного и того же процессора просто из компилятора Си одной фирмы в компилятор Си другой — частенько задача не для слабонервных. Да и написать новую программу с нуля гораздо лучше и проще, чем приспосабливать куски всякого старья. Иначе всю жизнь будешь решать задачи по шпаргалкам, копируя раз за разом одни и те же ошибки.
В принципе — согласен, что в пределах одного семейства процессоров переносить иногда сложно, но под переносимостью, в данном случае, я имеел ввиду переносимость кода в пределах абсолютно разных платформ. Скажем — какие либо функции, которые и под виндовсом и под линуксом и на арме одинаковую функциональность имеют и в авр их запихать можно не переделывая. Вот именно об этой переносимости все поклонники третьей буквы латинского алфавита и говорят, чтобы не изобретать заново какой либо алгоритм, который уже сделан и отлажен много раз.
А про «написать с нуля» попробуйте объяснить менеджеру проекта, который требует рабочую программу уже вчера, а с вашим «переписать с нуля» он ее получит через три месяца, но с уже новыми багами, которые потом столько же отлавливать надо.
Алексей
Всегда считал, что переносимость, это когда программа, которая компилируется и работает одинаково на нескольких платформах. Если надо что-то переписывать, то это портирование, а не переносимость.
Ну, межплатформенная переносимость реально возможна только на языках очень высокого уровня, полностью абстрагированных от железа, вроде Явы, и то не всегда. На микроконтроллерах же привязка к железу настолько жесткая, что даже перенос в пределах одного семейства требует некоторых доработок, а уж между контроллерами разных фирм — тем более. Например, похожие вроде таймеры разных контроллеров, например, PIC и AVR, в разных режимах ведут себя по разному, могут иметь разные пред- и пост- делители, режимы захвата, и прочее. Или, к примеру, быстродействие предделителей. Почти любой PIC, независимо от тактовой частоты, способен считать с внешнего входа до 70-80Мгц, для AVR — только единицы МГц (реально до 1-2). Попробуйте перенести с PIC на AVR программу популярного частотомера Денисова, хоть на асме, хоть на Си. (Я уж не говорю о том, что на Си программа по тому алгоритму вообще нормально работать не будет из за невозможности точно просчитать и откалибровать время работы разных веток из за интенсивного использования стека и непредсказуемой «оптимизации»).
Лично я понимаю переносимость только на уровне идеи, алгоритмов, и то с учетом вышеупомянутого.
А простая перекомпиляция листинга под другой контроллер — явление редкое. Только, если просто использовать аналогичный, но с большей памятью, или больше портов (Например, c Меги 16 на 32, или с PIC16F873 на 876,877).
А, к примеру, с Меги на PIC или Моторолу — проще заново… Если, конечно, программа сложнее, чем «HELLO, WORLD!».
Про привязку к железу скажу так — надо правильно писать программы. А именно — разделять сам алгоритм от уровня работы с железом — в народе называемом HAL — Hardware abstraction level. Это еще в школе проходят. И если обратить внимание на мой самый первый коммент тут — там написано: “…только HAL заменить и можно спокойно использовать программу…”. И если, например, в гермашке, на фирме, пишушей софт для автомобилей, вы будете делать программы, которые даже намека на HAL не имеют — долго не продержитесь. Вылетите сразу после того, как вашей проге Code review сделают. И не важно, что прога работает лучше и быстрее. На многих фирмах Code review — в простонародии это просмотр твоего кода посторонними для этого проекта, но знающими толк в программировании, людьми — обязательный этап выпуска ПО.
у нас эти люди называются «нормоконтроллёрами». самые важные люди в инсте и на производстве. по поводу программ — это и подсчёт числа отступов, и необходимые по СТП значки и символы (не комментарии, между прочи). для каждой функции — пояснения на пол-страницы, чтобы они поняли. они — это женщины-старушки от 50 и выше, которые компутеры увидали года 3-4 назад впервые. а т.к. у нас каждый чел пишет проги от 100к строк и выше по одиночке, то наше руководство решило, что группы тестеров нам не нужны, а нужны умудрённые годами НК. уж они то лажу не пропустят. доходило до того, что по СТП текст проги надо формлять в utf8. по мнению нормоконтроллёрши — это означает, что в каждом файле вначале должна быть надпись типа «text = utf8», а не то, что это должно значить на самом деле. некоторые перцы шли на принцип, оформляли как треба по ОСТам и по полгода пинались служебками, отвечая на вопросы «почему мой блокнот показывает крякозябры вместо русских буковок». итог всей этой деятельности такой. я пишу прогу месяц. одновременно приходится самому проверять и отлаживать на приборе. потом ещё около полугода сдаю её в архив через все препоны, а потом она летит в цскб или ещё куда, чтобы запулится в космос. зы! на такие нюансы, вроде «я принёс hex файл, а нормоконтроллёрша кликает по нему в проводнике и не может понять, почему не начинает на её виндовс мигать светодиодом, сигнализирующим об начале теста-калибровки» и всё такое согласно руководству оператора, я уже внимания не обращаю )
Ну на это я ничего не скажу. Скажу лишь, что у нас CodeReview делается не на проверку отступов, а на нахождение логических ошибок и проверяющего программер обязан сам выбрать из своих коллег! Т.е. проггер сам заинтересован в том, чтобы его код смотрел человек знающий то, на что он смотрит. А то, что у вас твориться — так это уже проблемы организации процесса, т.е. менеджмента и руководства — тут я только могу развести руками, и надеятся, что народ у вас может быть когда нить поумнеет. Кстати — менеджеры проекта тут — это бывшые проггеры — которые вкурсе, как программировать, и которые до менеджмента написали не мало строк работающего кода!
А если по сути книги? На сколько сложны примеры и код? Есть книга — «Белов А.В. Создаем устройства на микроконтроллерах». Вот там для ATiny2313 разобраны примеры на асме и Си. Правда примеры очень простые, но для старта подойдет.
Примеры там простые — вначале типа как диодом помигать, потом какой то девайс последовательно делают. ЕМНИП частотомер.
Программирование на языке Си для AVR и PIC микроконтроллеров Шпак Ю.А. 2-е издание, 2011 г.
В книге рассмотрено программирование на языке С микроконтроллеров AVR с использованием компиляторов WinAVR и CodeVisionAVR, а также микроконтроллеров PIC с использованием компиляторов CCS-PICC, mikroC и СЗО/32. Кратко рассмотрена архитектура и аппаратное обеспечение как традиционных восьмиразрядных микроконтроллеров AVR и PIC, так и новых семейств ATxmega, PIC24 и PIC32. Дано описание средств программной разработки, включая эмуляцию программ с помощью AVR Studio и MPLAB. Кратко рассмотрен стандартный синтаксис языка С и директивы препроцессора, а также особенности программирования на этом языке для микроконтроллеров. Книга содержит программные примеры на С, а также — справочник с описанием системы ассемблерных команд микроконтроллеров AVR (включая ATxmega) и PIC (включая PIC24).
Название: Программирование на языке С для AVR и PIC микроконтроллеров
Автор: Шпак Ю.А.
Издательство: Корона-Век, МК-Пресс
Год издания: 2011
Формат: djvu
Язык: русский
Страниц: 544
Качество: хорошее
Размер: 41.7 Мб
Краткое оглавление
Часть I. Архитектура микроконтроллеров AVR 15
Глава 1. Восьмиразрядные микроконтроллеры AVR 16
Глава 2. Семейство AVR ATxmega 97
Часть II. Компиляторы и средства разработки для микроконтроллеров AVR 140
Глава 3. Компилятор WinAVR 141
Глава 4. Среда разработки AVR Studio 146
Глава 5. Среда разработки CodeVisionAVR 158
Глава 6. Программаторы для микроконтроллеров AVR 175
Часть III. Архитектура микроконтроллеров PIC 184
Глава 7. Восьмиразрядные микроконтроллеры PIC 185
Глава 8. Семейство PIC18F 219
Глава 9. Семейство PIC24 231
Глава 10. Семейство PIC32 248
Часть IV. Компиляторы и средства разработки для микроконтроллеров PIC 260
Глава 11. Компилятор CCS-PICC 261
Глава 12. Эмуляция и отладка программ в среде MPLAB 275
Глава 13. Компилятор mikroC 282
Глава 14. Компиляторы С30 и С32 294
Глава 15. Программаторы для микроконтроллеров PIC 297
Часть V. Язык Си и директивы препроцессора 302
Глава 16. Основы языка Си 303
Глава 17. Функции и макросы языка Си для различных компиляторов 361
Часть VI. Программные примеры для микроконтроллеров AVR 412
Глава 18. Примеры для компилятора WinAVR 413
Глава 19. Примеры для компилятора CodeVisionAVR 430
Часть VII. Программные примеры для микроконтроллеров PIC 435
Глава 20. Примеры для компилятора CCS-PICC 436
Глава 21. Примеры для компилятора mikroC 446
Глава 22. Примеры для компилятора С30 453
Глава 23. Примеры для компилятора С32 470
Часть VIII. Приложения 477
Приложение А. Таблица символов ASCII 478
Приложение Б. Преобразование из одной системы счисления в другую 479
Приложение В. Система команд микроконтроллеров AVR 482
Приложение Г. Система команд микроконтроллеров PIC 498
Приложение Д. Область ввода/вывода микроконтроллеров AVR ATxmega А 519