Меню для управления через UART, на СИ Опции

[V000va]

Лирическое отступление
Поиском пользовался, фак читал. Нашел пару похожих топиков, но не то.
И все же...

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

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

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

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

Сообщение отредактировал V000va - Jan 23 2012, 22:15

[_Артём_]

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

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

Код

unsigned char ADCChannel;
#pragma vector=TCE1_OVF_vect
__interrupt void Timer1_16kHz_ISR()
{
    switch (ADCChannel) {
    case 0:
        ReadChannel(0);
        break;
    case 1:
        ReadChannel(1);    
        break;
    case 2:
        ReadChannel(2);
        break;
    
}

Об чём речь?

[_Ivana]

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

[_Pasha]

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

Сообщение отредактировал _Pasha - Jan 24 2012, 13:06

[V000va]

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



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

Код

while (1)
      {
      x=getchar();    
      delay_ms(200);
      switch (x) {
      case 'a': printf("\rRun ADC \r");  
      break;
      case 'b': printf("\rSetup PWM \r");
      break;
      default: printf("\rError \r");
      break;  
        };
      };

Сообщение отредактировал V000va - Jan 24 2012, 16:31

[_Ivana]

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

[=GM=]

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

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

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

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

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

[V000va]

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

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

[demiurg_spb]

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

[XVR]

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

[_Pasha]

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

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

[Dog Pawlowa]

ЗЗЫ Подойдет ли для этого обычное case ветвление?

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

[V000va]

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

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

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

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

[_Артём_]

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

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

[XVR]

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

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