Шпак Ю.А. Программирование на языке C для AVR и PIC микроконтроллеров

Автор:		Шпак Ю.А.
Название: 	Программирование на языке C для 
		AVR и PIC микроконтроллеров 
Издательство: 	МК-Пресс

Вот что я нарыл. Собственно, других книг по GCC я больше и не встречал. Одно время был классный мануал в виде chm файла, но потом он куда то делся и больше я его не видел. Так что качайте что есть :) Тут вначале рассмотрен сам язык Си, хуже конечно чем в оригинале от Кернигана и Ритчи, но зато обьемом поменьше. А дальше идет описание языка Си уже с упором на микроконтроллеры. Довольно кратко, но есть примеры, а это главное. Для PIC описывается компилятор CCS-PICC, а для AVR разобран GCC WinAVR.
Особо меня тут порадовал справочник в конце книги, где кратко расписаны все функции стандартной поставки CCS-PICC и GCC WinAVR с примерами. В общем, выбора у вас нет, раз ленитесь писать на ассемблере, то придется разбираться вот по этой книжке :)

23 thoughts on “Шпак Ю.А. Программирование на языке C для AVR и PIC микроконтроллеров”

  1. я во всех ваших спорах «си против асма» уже участвовать не хочу )
    но может кому-нить си на 4к доступной памяти и пригодится…

    зы! хотя я лично, когда юзал отладочную платку с армом9 и линухой на нём, использовал этот самый си там аж на процентов 90 )

    ззы! с програмерством на вижеле, гэцэцэ и всех средах, вплоть до эклипса, знаком )

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

        си для армов — это компромисс цены, времени и производительности. всё как в физике — выигрыш в усилении компенсируется устойчивостью и всё такое…

  2. Ну тут спорить особо не стоит, конечно. Но как мне кажется — основное преимущество С — это переносимость программ на разные контроллеры — только HAL заменить и можно спокойно использовать программу несколько раз, а не изобретать велосипед заново.
    Алексей

    1. Переносимость — понятие растяжимое… (В принципе, и из любого приемника, даже детекторного, можно сделать телевизор, добавив недостающие детали).
      Перенести программу, например, c Меги 16 на 32 — и в ассемблере не проблема.
      А, к примеру, с АРМ на Тини — никакой С не поможет.
      Ну, а с определенными оговорками — любой язык высокого уровня обладает переносимостью, если не использовать абсолютные адреса. Но только поклонники третьей буквы латинского алфавита упорно твердят об этом, доводя, в общем — то, неплохую идею, до абсурда. В то же время даже перенести программу для одного и того же процессора просто из компилятора Си одной фирмы в компилятор Си другой — частенько задача не для слабонервных. Да и написать новую программу с нуля гораздо лучше и проще, чем приспосабливать куски всякого старья. Иначе всю жизнь будешь решать задачи по шпаргалкам, копируя раз за разом одни и те же ошибки.

      1. В принципе — согласен, что в пределах одного семейства процессоров переносить иногда сложно, но под переносимостью, в данном случае, я имеел ввиду переносимость кода в пределах абсолютно разных платформ. Скажем — какие либо функции, которые и под виндовсом и под линуксом и на арме одинаковую функциональность имеют и в авр их запихать можно не переделывая. Вот именно об этой переносимости все поклонники третьей буквы латинского алфавита и говорят, чтобы не изобретать заново какой либо алгоритм, который уже сделан и отлажен много раз.
        А про «написать с нуля» попробуйте объяснить менеджеру проекта, который требует рабочую программу уже вчера, а с вашим «переписать с нуля» он ее получит через три месяца, но с уже новыми багами, которые потом столько же отлавливать надо.
        Алексей

      2. Всегда считал, что переносимость, это когда программа, которая компилируется и работает одинаково на нескольких платформах. Если надо что-то переписывать, то это портирование, а не переносимость.

        1. Ну, межплатформенная переносимость реально возможна только на языках очень высокого уровня, полностью абстрагированных от железа, вроде Явы, и то не всегда. На микроконтроллерах же привязка к железу настолько жесткая, что даже перенос в пределах одного семейства требует некоторых доработок, а уж между контроллерами разных фирм — тем более. Например, похожие вроде таймеры разных контроллеров, например, PIC и AVR, в разных режимах ведут себя по разному, могут иметь разные пред- и пост- делители, режимы захвата, и прочее. Или, к примеру, быстродействие предделителей. Почти любой PIC, независимо от тактовой частоты, способен считать с внешнего входа до 70-80Мгц, для AVR — только единицы МГц (реально до 1-2). Попробуйте перенести с PIC на AVR программу популярного частотомера Денисова, хоть на асме, хоть на Си. (Я уж не говорю о том, что на Си программа по тому алгоритму вообще нормально работать не будет из за невозможности точно просчитать и откалибровать время работы разных веток из за интенсивного использования стека и непредсказуемой «оптимизации»).
          Лично я понимаю переносимость только на уровне идеи, алгоритмов, и то с учетом вышеупомянутого.
          А простая перекомпиляция листинга под другой контроллер — явление редкое. Только, если просто использовать аналогичный, но с большей памятью, или больше портов (Например, c Меги 16 на 32, или с PIC16F873 на 876,877).
          А, к примеру, с Меги на PIC или Моторолу — проще заново… Если, конечно, программа сложнее, чем «HELLO, WORLD!».

          1. Про привязку к железу скажу так — надо правильно писать программы. А именно — разделять сам алгоритм от уровня работы с железом — в народе называемом HAL — Hardware abstraction level. Это еще в школе проходят. И если обратить внимание на мой самый первый коммент тут — там написано: “…только HAL заменить и можно спокойно использовать программу…”. И если, например, в гермашке, на фирме, пишушей софт для автомобилей, вы будете делать программы, которые даже намека на HAL не имеют — долго не продержитесь. Вылетите сразу после того, как вашей проге Code review сделают. И не важно, что прога работает лучше и быстрее. На многих фирмах Code review — в простонародии это просмотр твоего кода посторонними для этого проекта, но знающими толк в программировании, людьми — обязательный этап выпуска ПО.

            1. у нас эти люди называются «нормоконтроллёрами». самые важные люди в инсте и на производстве. по поводу программ — это и подсчёт числа отступов, и необходимые по СТП значки и символы (не комментарии, между прочи). для каждой функции — пояснения на пол-страницы, чтобы они поняли. они — это женщины-старушки от 50 и выше, которые компутеры увидали года 3-4 назад впервые.

              а т.к. у нас каждый чел пишет проги от 100к строк и выше по одиночке, то наше руководство решило, что группы тестеров нам не нужны, а нужны умудрённые годами НК. уж они то лажу не пропустят.

              доходило до того, что по СТП текст проги надо формлять в utf8. по мнению нормоконтроллёрши — это означает, что в каждом файле вначале должна быть надпись типа «text = utf8», а не то, что это должно значить на самом деле. некоторые перцы шли на принцип, оформляли как треба по ОСТам и по полгода пинались служебками, отвечая на вопросы «почему мой блокнот показывает крякозябры вместо русских буковок».

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

              зы! на такие нюансы, вроде «я принёс hex файл, а нормоконтроллёрша кликает по нему в проводнике и не может понять, почему не начинает на её виндовс мигать светодиодом, сигнализирующим об начале теста-калибровки» и всё такое согласно руководству оператора, я уже внимания не обращаю )

              1. Ну на это я ничего не скажу. Скажу лишь, что у нас CodeReview делается не на проверку отступов, а на нахождение логических ошибок и проверяющего программер обязан сам выбрать из своих коллег! Т.е. проггер сам заинтересован в том, чтобы его код смотрел человек знающий то, на что он смотрит. А то, что у вас твориться — так это уже проблемы организации процесса, т.е. менеджмента и руководства — тут я только могу развести руками, и надеятся, что народ у вас может быть когда нить поумнеет. Кстати — менеджеры проекта тут — это бывшые проггеры — которые вкурсе, как программировать, и которые до менеджмента написали не мало строк работающего кода!

  3. А если по сути книги? На сколько сложны примеры и код? Есть книга — «Белов А.В. Создаем устройства на микроконтроллерах». Вот там для ATiny2313 разобраны примеры на асме и Си. Правда примеры очень простые, но для старта подойдет.

    1. Примеры там простые — вначале типа как диодом помигать, потом какой то девайс последовательно делают. ЕМНИП частотомер.

  4. Ди, а можно как-то позырить, как реализованы эти стандартные функции в gcc ? В заголовочном файле только их описание.

      1. мне интересно, как он тригонометрические функции считает. 1000 тактов и 32битные переменные — боюсь, я не разберу того, что мне компилятор наколдует %) Надо попробовать набыдлокодить синус через cordic

Добавить комментарий

Ваш e-mail не будет опубликован.

Перед отправкой формы:
Human test by Not Captcha