День добрый, есть AVR-ка, хотелось бы управлять через UART внутренним АЦП (on/off), ШИМ (менять значения), on/off некоторых пинов контроллера.

Как лучше всего организовать/построить подобное меню? Опыт программирования у меня не большой, посему и спрашиваю.

Подскажите в какую сторону копать, или простой примерчик для начинающих.

ЗЫ Планирую использовать прерывание для АЦП.
ЗЗЫ Подойдет ли для этого обычное case ветвление?

Для чего подойдёт case?
просто написать в программе case - будет ошибка.
Или


Об чём речь?

В зависимости от того, на чем вы пишете (С или asm) - определите спиок глобальных переменных или адресов ячеек ОЗУ, которые будут определять параметры вашей системы: менять ШИМ, включать/отключать пины и т.п. При инициализации заполняете их дефолтными значениями. Потом самостоятельно разработайте "протокол" управления этими параметрами - что должно прийти по UART чтобы какой-то параметр поменялся и как. А потом принимаете по UART все что пришло, анализируете это (если быстро - можно прямо в прерывании) и в согласии с протоколом управления меняете управляющие переменные/ячейки ОЗУ. Если систему управления параметрами масштабировать, то можно параллельно управлять этими же переменными через любые другие входящие воздействия - по любому другому интерфейсу или по нажатию кнопок на пинах.

"Сферические" задачи даются студентам для развития фантазии.
Вы бы лучше сами набредили, причем поподробнее, несколько вариантов, затем, после нескольких уточнений, выбрали бы нормальный вариант. Причем, сами бы выбрали. А так - что толку заунывно начитывать:
*Какой физ. уровень будет RS232 RS485/422?
*Одно устройство или несколько?
*Надо, чтобы любой МК понимал одинаковые команды или по принципу "указал адрес регистра, указал команду читать или записать, указал данные(если записать)"
итд итп список может быть длиннее

Видимо я не очень ясно изложил чего хотел. Да в общем-то не так уж и много, хочу управлять ШИМ-ом через UART и считывать данные с АЦП. Нужно какое-то меню, чтоб этим всем управлять. Вот я и советуюсь, какое направление выбрать.
Планирую делать меню через case. С АЦП понятно - дал команду- пошло преобразование, отбразилось в терминале. Но не знаю как вводить данные в OCR0 для управления ШИМ, а точнее как осуществить загрузку в OCR0. Загрузить не какую-то предустановленную величину из меню, а любую из доступного диапазона.
На счет case я не уверен в общем-то, возможны варианты, покритикуйте если что.



PS Ну а тем кому лениво/уныло читать, могут и не читать, дело-то добровольное, они либо родились уже с программированием на СИ в голове и круче Денниса Ритчи, либо забыли как сами разбирались и учились.

Непонятно, что именно вам непонятно в данных ответах. Вы сами смутно догадываетесь, что даже если вы по 'A' запустите ЦАП, по 'B' его выключите, сами символы засунете по UART через терминал с компьютера или ещё какого источника, то изменять скважность ШИМ так запросто не выйдет - надо передавать двухбайтовое число по UART. Как - вопрос второй. Можно именно в паре байт, но тогда вы не с любого терминала наберете возможные символы, соответствующие этим кодам. Можно в десятичном представлении - но тогда придется его потом переводить в пару байт. Это и называется "разработайте протокол" управления вашими устройствами. А вы вцепились душой в этот case и очередной раз спрашиваете, поможет ли он вам. Не об этом надо думать, а о протоколе, конкретно - как передавать параметр скважности ШИМ.

Как правило, для одного пункта меню нужно передать несколько байт, например, для шим надо передать пакет-сообщение, содержащее команду ШИМ и один-два байта заполнения шим.

Но как определить начало сообщения? Надо разработать структуру пакета. Лучше начать с пакета фиксированной длины. Итак, пакет должен состоять из заголовка, команды, данных и контрольной суммы. Предлагаю такой формат: 0x0B,0x77,CMD, data1,data2, CRC.

Здесь первые два байта - заголовок, CMD - байт команды, обычно одного байта достаточно, затем data1,data2 - два байта данных, затем два байта контрольной суммы.

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

А то, что вы написали, вполне подойдёт для разбора принятой команды.

_Ivana и =GM= Спасибо, вот это уже что-то! Возможно я использовал не ту терминологию и меня не поняли, но не беда. Так намного яснее! Про загрузку ШИМ, колцевой буфер, протоколо - это именно то, что нужно. Теперь яснее в чем разбираться.
А именно в:

1. Кольцевой буфер
2. Пртокол

Если есть желание развивать свой проект, то советую не изобретать свой протокол.
Для управления пром-контроллерами со схожим вашему функционалу обычно применяют modbus-rtu.

Вопрос к ТС: вы своим устройством собираетесь управлять по RS232 из обычного терминала, или через какую то программу на РС?
В первом случае вам нужет текстовый командно ориентированный протокол, во втором подойдет любой бинарный, главное что бы был попроще

Ну уж нет! RTU - это для контроллера более высокого уровня. А подобные штуки, относящиеся к "умным" измерителям или регуляторам лучше заводить в отдельный сегмент и чтоб они общались по гораздо более простому протоколу.
Как вариант только не судите строго, там могут быть баги, первая система с использованием сего чуда будет только через пару недель, пока только железо собираю.

Желательно не в прерывании.
Научитесь сначала организовывать какие-то независимые действия - измерение, прием сообщений, отправка сообщений.

Управлять будут из внешней программы, но с возможностью ручного управления из меню терминала.



Пясните плз, не использовать case в прерывании RX_uart или из меню не вызывать действий приводящим к прерываниям?

Организовать программу по-другому:
В прерывании RX_uart писать в круговой буфер;
В основной программе проверять индексы буфера приёма и если буфер не пуст, обрабатывать принятые данные (case ....);
АЦП запускать по таймеру или ещё как-нибудь (использовать прерывание АЦП);
И тд - обеспечить псевдопаралельность исполнения всех задач, а не ждать байта в getchar.

Тогда однозначно текстовый командный протокол

ТС, Вам правильно сказали: делайте все поэтапно. Сначала сделайте и отладьте измерение, затем разберитесь с UART (настройки и т.д., без использования прерываний), затем просто (без запроса) отправляйте результаты измерений в текстовом виде в UART (например, ежесекундно), чтобы можно было увидеть терминалом на ПК. А вот потом уже можно браться за реализацию протокола. Это может быть и какой-нибудь стандартный (например, Modbus). А если Вы хотите управлять с терминалки (текстом), то начать можно с простого: составьте список команд-символов, по приему которых Ваш прибор будет выполнять соответствующие действия, и приступайте к их реализации. В принципе, если получится реализовать Modbus, то это будет плюсом - протокол довольно распространенный, и круг применения Вашего устройства будет гораздо шире. Для тестирования slave-устройств полно программ для ПК.