Уроки СИ для AVR микроконроллеров

[sva-don]

Давненько я сюда не заходил.
Начну с языков. Лично я их распределяю по двум признакам.
1. Легкость, с которой можно написать ПО для МК.
2. Для чего вообще пишется это ПО и создается МК.
На этой базе можно легко классифицировать все остальное.
Я частично согласен с Юрием, что развращенность ресурсами приводит к неряшливости, но давно прошли те времена, когда приходилось считать каждый байтик. Современные процессоры стоят копейки, а их возможности намного превосходят те, которые были ранее. По этой причине нет никакого смыла сидеть ночами и "ужимать код" до приемлемой величины. Лучше направить свои усилия на поиск "жучков" и улучшение функциональности создаваемого устройства, его привлекательность для потенциальных заказчиков.
Что касается языков, то тут каждый волен выбирать то, что ему по вкусу. Для людей фанатеющих от ASMа и тех, которые завидуют знатокам, хочу сказать, что это самый непроизводительный путь к готовому изделию. Вспоминаю времена КР580-го. Первую программу для которого я писал в 1981 году. Это была игрушка "Питон", кто помнит - это змея, которая ела на экране квадратики и росла. Все на ассемблере. Это было просто адское занятие. Голова, как барабан, по ночам снились нолики и единички...
Современные языки позволяют относительно комфортно все это пережить. Не важно на чем вы пишете, важно изучить язык во всех его тонкостях.
Те критичные, в основном по быстродействию куски кода легко интегрируются в программы на любом языке.
Для того, чтобы не разочароваться, самым доскональным образом изучите даташиты на все микросхемы. ПОнимая, что с языками не у всех все в порядке, но это просто необходимо. Ни в коем случае не пользуйтесь автопереводчиками, они иногда такое напишут, что волосы дыбом становятся. Буду настаивать на том, чтобы в качестве ядра брать максимально мощный процессор. Его можно изучать в процессе написания ПО. Скорее всего так и придется делать, т.к. читать документацию и представлять все, что у него внутри весьма сложно, нужно сразу щупать.
Если вам нужен быстрый результат и готовое изделие советую Васик. Если ваша цель просто научиться программировать на том или ином языке, то берите его. Часть программы ОБЯЗАТЕЛЬНО пищите на ASMе, даже если это и не нужно для проекта. Это заставит вас изучать и процессор и ассемблер.
Повторюсь. Изучайте все по порядку. I2C, SPI, 1Wire, RS232, периферию процессора. Сам иногда зацикливаюсь на программе, а потом с удивлением понимаю, что это есть у процессора внутри.
Если планируете заниматься этим профессионально, то выбор конечно же С и только С. Для себя Васик.

[sva-don]

Сообщение от sva-don

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

Многие советуют наоборот: выбрать средний МК и освоить его досканально. Для любительских целей он более доступен и самодостаточен. Огромный обьем памяти и производительности приводит к неряшливости (например размер и поглощение ресурсов ОС Windows - Мелкософт уже не старается оптимизировать код). Думается, что человек привыкший к Мерседесу, врядли сядет на Жигули. К хорошему привыкаешь быстро.

Полностью согласен, зачем покупать Жигули, если можно сразу приобрести Мерс?

Прикрепленный файл: 9622392.zip

[sva-don]

Сообщение от sva-don

Не нужно разбрасываться сразу на конкретное изделие. Можно просто взять какую либо идею, но так, чтобы в ней было все: LCD, I2C, SPI, INT, RS232 и т.д. и т.п. Затем пошагово ее исполнять. Т.е. добиваться по каждой теме безукоризненного выполнения кода и полной ясности в голове по изученной теме. Тогда будет толк. Не в коем случае не забывать ASM.

А товарисч абсолютно прав... нужно сначала отработать каждый интерфейс а потом всё увязывать вместе..
Да так распределить ресурсы МК, что бы со всеми устройствами МК работал ПАРАЛЕЛЬНО, То есть если обрабатывается скажем вывод в ЖКИ и пришёл байт от USART да ещё идёт запись в I2C и по 1WIRE считываем ключ iBatton или температуру с DS18B20, то что бы все события были обработаны... тогда у вас ни одно устройство никогда ничего не пропустит и не подвиснет...

Сообщение от yuriji

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

А каким он видится??? этот урок... А вообще то пора осваивать Си..
Вот я начал учить Си и предложил на форуме организовать что то типа учебного пректа по Си...
Слишком сложно от АСМ переходить к Си без пинка под зад..
Но идею не восприняли.. вот сейчас сам разбираюсь.. попозже попробую таки этот проект создать..
Уже написал один проект и понял, Си избавляет от многих рутинных вещей. Но между процесором и мной появляется прокладка - компилятор, и нужно уметь объяснить компилятору что ты хочеш, что бы он откомпилировал так как ты бы написал на асме.

Распределение ресурсов МК дело не совсем тривиальное, но и не самое страшное. На днях выложу алгоритмик, скелетик программы, там все будет ясно.
Прокладка компилятор не страшная вещь. Я уже отметил, что в любом языке можно делать вставки на ASMе. Можете вообще в Сишном компиляторе написать все на ассемблере.
Преподать урок на ассемблере, конечно можно, но думаю, что это не нужно. Проще задавать конкретные вопросы по текущему проекту. Т.е. появился вопрос, требующий ассемблера, задаете его на форуме и сообща он решается. Еще раз подчеркиваю, что выбор языка дело личной предпочтительности. Я, например С не люблю. Стараюсь все писать на Васике.

[IOPA4]

Асмом баловался в период Синклара. Нужно было быстродействие, т.к. машинка слабая (например писал светомузыку и Питона тоже ) Бейсик тоже мне нравился. Для него были компиляторы, для перевода в ЕХЕ. Делал машинные вставки, где нужно быстродействие. Но учтите мой возраст и наличие времени, сейчас я даже не могу представить, что я буду сидеть с калькулятором и вычислять адреса переходов и куда какой бит поставить, проверять флаги. Т.к. я давно еще изучал Си и паскаль, то мне легче писать на СИ. Полная наглядность и отлов ошибок в дебаггере. Я думаю, что не зависит на каком языке написана программа, а результат CVAVR в асме я тоже иногда просматриваю и вроде бы все Ок, но в устройстве есть такой глюк. Когда касаешься платы или дисплея появляются крякозябры, программа при этот работает (вставлял через минуту lcdinit(16))и через минуту инфа перепрописывалась, но раздражает ежеминутное дерганье ЖКИ. Как избавиться от этого?
1. Поменять язык
2. Поменять МК на более мощный
3. Или что-то еще?

-- Прилагается рисунок: --

[daddy]

Когда касаешься платы или дисплея появляются крякозябры, программа при этот работает (вставлял через минуту lcdinit(16))и через минуту инфа перепрописывалась, но раздражает ежеминутное дерганье ЖКИ. Как избавиться от этого?
1. Поменять язык
2. Поменять МК на более мощный
3. Или что-то еще?

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

-- Прилагается рисунок: --

[IOPA4]

А вообще-то этот спор не по сути:
1. Мне думается, что компилятор способен создать нормальный машинный код. Тем более, что многие команды и фунции подменяются давно отработанным машинным кодом. Кто волокет в Асме - загляните в папку CVAVR и изучите асм-файл. Скажите свое мнение.
2. Атмел не зря выпускает такое разнообразие МК. Там есть и тини, и меги, и еще посерезнее. Или тини это для нищих, меги для среднего класса и т.д. Зачем на самосвале возить ведерко песочка? В этом проекте нужно было только три порта, да пару таймеров. Затем задача перешла и в экономичность. Снижена частота МК до разумных пределов. В общем Атмеги8 за глаза. Да еще в нете появилась информация, что не применяйте 16 и 32 Меги, там есть глюк, ну а 64, 128, 256 Меги применять для этого проекта по-барски, тем более, что мне на моем обьекте нужно установить их десяток, моему другу около 40. Из-за чего перешли на светодиодный индикатор - он в два раза дешевле и оказалось, что схема с ним и надежней.

[IOPA4]

Сообщение от IOPA4

Когда касаешься платы или дисплея появляются крякозябры, программа при этот работает (вставлял через минуту lcdinit(16))и через минуту инфа перепрописывалась, но раздражает ежеминутное дерганье ЖКИ. Как избавиться от этого? 1. Поменять язык 2. Поменять МК на более мощный 3. Или что-то еще?

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

Я же писал, обычная статика. Сбоя программы нет, а вот память контроллера сбоит.

-- Прилагается рисунок: --

[daddy]

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

[daddy]

Кстати, если вставить дисплейные процедуры на асме, то и мерцание прекратится, и память освободится. 8O

[andries5]

Может не в тему, но для лучшего понимания AVR,
я решил написать генератор начальног кода под WINAVR.
Вот уже больше месяца не вылезаю из даташитов.
Возможно зря, но правда стал понимать логику работы.
Если бы писал на CVAVR разные задачи, видимо было бы
лучше. Но генератор закончу.