Книга по СИ для AVR.

AVR
Нарыл недавно клевую книженцию автора Романа Абраша. Называется Книга по работе с WinAVR и AVR Studio. Книга автором не дописана. Но хоть что то есть, и то что есть, мне понравилось.

Вот цитата из его книги:
Как известно, программы разрабатываются на языках программирования, среди которых наибольшей популярностью пользуется Си. Благодаря основам, заложенным в этот язык, разработка программ для микроконтроллеров мало отличается от разработки программ для обычных компьютеров. Поэтому проще всего переключиться на микроконтроллеры смогут те, кто уже умеет хоть немного программировать для персонального компьютера. А все остальные желающие могут прочесть специальные книги, посвященные как самому языку Си, так и процессу алгоритмизации. Литературы на этот счет достаточно, равно как и литературы об аппаратном строении микроконтроллеров. А вот книг, которые целенаправленно рассматривали бы аспекты «сопряжения» языка программирования и микроконтроллера, явно недостаточно. Восполнить этот пробел хоть в какой-то мере – вот главная цель и задача этой книги.

Вот существующие главы его книги.


А вот ссылка на спец книгу по СИ.
Загружать эти файлы.


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

P.S
Вот еще нарыл очень четкий справочник по СИ. Чтоб справочник запустить, нужно в открыть файл main.htm

А вот он же, только в онлайн режиме.

А вот книга «Программирование микроконтроллеров ATMEL на языке С — Прокопенко Вадим».

Комментарии (39)

RSS свернуть / развернуть
Мне очень понравилась фраза автора:
А вот книг, которые целенаправленно рассматривали бы аспекты «сопряжения» языка программирования и микроконтроллера, явно недостаточно.

В общем то это первая книга которую я нарыл по данной теме. Не ну есть правда еще одна Лебедев CodeVisionAVR. Пособие для начинающих 2008_Язык СИ.djvu ну и эта Шпак Ю.А. Программирование на языке С для AVR и PIC микроконтроллеров.2006.djvu больше книг не знаю. Эти книги здесь есть.
0
Я себе купил Разработка устройств на микроконтроллерах AVR: шагаем от «чайника» до профи. Книга + видеокурс — Белов
Пожалел что выбросил столько денег. Не знаю какого мнения про этого автора другие люди, но как по мне ему лучше ничего обучающего не писать. На дворе 2013 год, а он описывает как собрать ЛПТ-программатор.
0
Полностью согласен. На асме код работает, а вот на С, приходится исправлять ошибки.
0
автор этой книги был на радиокоте одно время
0
Не, ну за «Спец книгу по Си» я оставлю плюсик.
0
Вот еще мне очень понравилась вот эта книженция Программирование микроконтроллеров ATMEL на языке С — Прокопенко Вадим Тут автор описывает «взрослые» вещи. Это скорее не книга, а джентельменский набор для бистрого запуска любой переферии в АВРках.
0
Какой компилятор описывается там?
0
В качестве средств разработки и имитации использованы компилятор WinAVR, среда AVR Studio и имитатор схем Proteus ISIS
0
Ты ее уже скачал?
0
ага :)
DJVU (71Mb) — вычищен от мусора, без OCR, но некоторые пункты содержания с гиперссылками (видно, что над сканом хорошо поработали)
На CD — в основном, место занимают старые дистрибутивы AVRStudio, WinAVR и демо Proteus. Полезного там ~50Mb (документация и исходники программ по книге).
0
Можешь скинуть этот торрент файл? тоже хочу скачать и глянуть чего там интересного.
0
magnet:?xt=urn:btih:F8AC9CF8456BC1139243C0E7CADCD9E38F797FFF
0
Дык, та раздача «платиновая» (Платина) — можно скачать и без регистрации… Жми на картинку «магнита» (Примагнититься) — получишь магнет-ссылку на книгу, их можно скачать без регистрации обычным торрент-клиентом (uTorrent: «Файл \ Добавить торрент из URL...»).

magnet:?xt=urn:btih:F8AC9CF8456BC1139243C0E7CADCD9E38F797FFF
0
Ух ты! Спасибо! Качаем… )))))
0
Да, это достойная книга. Так она еще и в цене подросла.
0
Интересненько!.. Спасибо!
.
Вот бы еще про ARM так кто-нибудь «как для 3-х летних детей» разжевал, да в рот положил… Или в садике ARMы еще не учат? УжЕ только в школе? Пичалька… :(
0
Ну я думаю в свое время, и это появится. Просто ARM более свежее, поэтому мало чего еще есть.
0
Да нет, производиться они начали в тех же 90-х годах XX века, что и AVR, и PIC. В среде радиолюбителей, да, ARMы недавно начали обретать популярность.
0
Плохо, что в главах «Основы Си» рассказ не о Си, а о «Си для AVR». В результате — непереносимый код, непонимание почему код, работающий на AVR, не работает на ARM. Кроссплатформенность? Не, не слышал.
0
В дальнейших главах автор пишет про переносимость кода. И всякие неприятности связанные с этим. Как раз таки цель книги это и есть Си для AVR, а не просто Си.
0
интересно в чем отличие «просто С» от «С для авр»
0
Э… ну хотя бы в том что язык СИ ориентирован на архитектуру фон-Неймана, то-есть когда и данные и код находятся в едином адресном пространстве. А в микроконтроллерах AVR адресация «памятей» разная, не находятся в едином пространстве, поэтому возникают различные нюансы как на СИ программировать такое железо. Вот и появляются дополнительные нюансы типа введенных макросов PROGMEM, pdm_read_byte, и так далее и тому подобное. Об этих вещах просто в книгах по СИ вообще ничего нету и не будет и это понятно почему. О таких тонкостях программирования надо читать в спец книгах по СИ для AVR.
0
Для этого не нужна отдельная книга по С, достаточно книжки по особенностям его использования для AVR.
Впрочем, лично мне вообще достаточно документации на компилятор.
0
Как-то в основах си многовато лишнего. В целях любопытства узнать можно, но новичку-то зачем?

Вместо всяких unsigned short с кучей примечаний про «по умолчанию» лучше б про stdint-типы сразу, чтоб раз и навсегда. Про ключевые слова типа register лучше вообще умолчать, как и про goto. Или написать в конце с пометкой «атата». С volatile надо быть очень осторожным, extern тоже лучше не использовать.

Хотя разделы «основы си» позиционируются как справочник, а не учебник…
+2
extern тоже лучше не использовать.
Почему?
0
За исключением особых случаев, все переменные лучше если будут внутри тех модулей (файлов то есть), где они объявлены.
Размазывание переменной на 50 файлов, чтоб потом и концов не сыскать — это не очень хорошее решение.

К исключениям могу отнести какие-то ресурсы большого размера (массивы с музыкой/картинками/таблицами), которые размещаются в c-файле, компилируемом отдельно или какие-то общие переменные типа настроек прибора, которые сосредоточены в одной структуре и нужны везде. Почти во всех остальных случаях использование extern малоуместно=)
+1
За исключением особых случаев, все переменные лучше если будут внутри тех модулей (файлов то есть), где они объявлены.
А если переменная используется в разных файлах и прерываниях еще?
+1
… если переменная используется в разных файлах...
Именно для этого и служит спецификатор extern — для описания глобальной переменной, используемой в нескольких файлах. Например, это может быть переменная, определённая в библиотеке, к которой должны обращаться ваши функции.
Я полагаю, teplofizik хотел сказать, что таких глобальных переменных должно быть минимально необходимое количество и вообще, область видимости переменных должна быть минимально необходимой.
+1
Ага, именно. Инкапсуляция — хороший метод снижения зависимости модулей друг от друга. Что влечёт упрощение поддержки в будущем, да и вообще более грамотно.

Чем меньше потрохов торчит наружу — тем всем лучше.
+2
область видимости переменных должна быть минимально необходимой.
Предположим у меня в проекте включено с десяток прерываний МК (все условно). Ну и в каждом прерывании используется по 10 переменных. Итого получается 100 переменных используется только в прерываниях. Ну и предположим эти переменные используются и в основном цикле. Как тогда быть? Ведь все они являются глобальными. Получится что много
потрохов торчит наружу
0
Много или не много — вопрос относительный. Наружу должно торчать такое количество, без которого нельзя или очень трудно обойтись. Если переменную можно спрятать — её нужно спрятать. Если нельзя обойтись без глобальной переменной — ну, значит так надо. Но это должно быть взвешено: надо или не надо?
Представьте себе законченное электронное устройство в корпусе. Какие входы-выходы должны быть выведены наружу? Какие разъёмы на передней панели, какие на задней? Какие органы управления необходимы каждый день, а какие регулировки будут только настроечными-ремонтными?
+3
Если вам надо использовать сто переменных от десяти прерываний в главном цикле, то с дизайном проекта что-то очень не так =)

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

Проблему с гигантским циклом можно решить, например, введя для каждого модуля функцию, которая вызывается из главного цикла и делает всё то, что вы пихали раньше прямо в главный цикл:
while(1)
{
...
dsp_main(); // экран
...
}

Кода от этого, конечно, меньше не станет, но он будет логически разделён.
И не нужно никаких переменных вытаскивать за пределы модуля, например, экрана — dsp_main их и так у себя видит, а остальному они и не нужны. Управление, естественно, тоже можно сделать через функции.
+2
Если вам надо использовать сто переменных от десяти прерываний в главном цикле, то с дизайном проекта что-то очень не так =)
А разве такого не может быть?
0
Может, но в одном файле это будет ужасно =)
0
Не должно, во всяком случае. Обычно из прерывания наружу торчит очень не много (если вообще торчит). При использовании, например, очередей или семафоров, может и вообще не торчать ничего. А локальное состояние обработчика прерывания, которое ему нужно хранить между вызовами, вполне логично запихать в локальные статические переменные, тогда они и в пределах модуля под ногами не будут путаться.
+1
Да интересно все это. Эх слабоват я еще в СИ, учиться и учиться…
0
Таких кошмаров можно наделать на любом языке программирования. Как было замечено выше, это вопрос дизайна проекта.
0
Непонятно, за что заминировали комментарий teplofizik . Ведь коллега прав, лучше избегать экспорта переменных из модуля. В большинстве случаев, при правильной декомпозиции кода (в данном случае, разбитие кода на модули) этого можно (и нужно) избежать.

Естественно, это не правило, скорей настоятельная рекомендация. Существуют (редкие) исключения исходя из конкретной реализации. Но в общем случае — коллега прав, (как и EW1UA ), без особой необходимости не нужно расширять область видимости функций/переменных. Инкапсуляция рулит :) Чем меньше связей между модулями — тем лучше.
+1
Только зарегистрированные и авторизованные пользователи могут оставлять комментарии.