@oski12345

Здравствуйте! Не знал куда отправить этот вопрос. Прошу помощи!
вкратце:
моя задача разработать прошивку для мк AVR ATmega16, входящего в состав платы сопряжения с компьютером зарядного устройства(ЗУ), плата сопряжения мереет выходное напряжение ЗУ(стоит АЦП), задаёт заданное для ЗУ(с помощью ЦАП), выводит и то и другое на ЖКИ и позволяет осуществлять с компьютера управление ЗУ по интерфейсу RS-232(запуск, остановку, передачу заданного значения для ЦАП) и считывание информации(о состояниии, измеренном АЦП напряжении и заданном для ЦАП значении).
Собственно сами вопросы:
Есть система команд [205.4 Кб]

и куча вопросов по ней.
Я воспринял её так:
1) Команда чтения состояния. Запрос занимает 4байта. Ответ 7байт: под (ацп) я отвёл 2 байта(думаю надо передавать в коде, а не в В, максим-е зн-е 0xFFFF - соответствует 16-битному АЦП); под (блок)(сост) я отвёл 1 байт(для примера код 0х12 - это готов и разомкнута цепь вн.блокировки); (ошибка) думаю тоже 1 байт, ещё начальный конечный символ и адрес - итого 7байт. почему в примере у них такой ответ я не догнал чуство что (ацп) передаётся не в хексах а в символах или ещё как то да и не в кодах а в В зачем это..
2) Команда чтения задан. напр. и напр. отс. Запрос занимает 4байта. Ответ 7байт: под (ЦАП) и (U_отсечки) я отвёл по 2 байта на каждое(так же в кодах и там и там максим-е зн-е 0xFFFF). Зачем (U_отсечки) делённое на 100 вообще не догнал..
3) команда управления. Запрос по моей логике занял 8байт: под (0) я отвёл 1 байт, под (мощность)(заряд) - 1 байт, (ЦАП) - 2 байта, итого 8байт. Ответ-3байта.
4)Команда задания напряжения отсечки. Под каждый (0) отвёл по 1байту, под (U_отсечки) снова 2 байта, итого получил вместе со всем прочим 11 байт.

Не совсем понятно так же как эти все эти байты в прерывании по приёму RXD собрать в команду если (ЦАП) в хексах передавать ведь в составе команды могут быть символы начала и конца строки..

В общем я окончательно запутался правильно ли я это всё понял.. да и к кому обратиться .. Ктсати наверно важно - подобных устройств там уже куча и они все уже управляются поэтому думаю систему команд мне менять по моему усмотрению никто не позволит.. Если кто дочитал до конца - уже отдельное спасибо)

0

@stt

Нет. Ответ 10 байт + символ начала передачи и символ окончания. Под АЦП отводится 5 байт. Если не соблюсти формат посылки, оконечное устройство вас не поймет.
Вы передаете десятичное число в ASCII формате. Оно не принимает значения символов начала и конца строки.

0

Th0r

запрос занимает 6 байт
1 - $
2 и 3 - 16ричные цифры в ASCII формате
4 - символ "3"
5 - символ "0"
6 - символ 0x0D (перевод строки)

@soumt_imobti

Я понимаю, что для готового устройства никто не будет менять систему команд, но на будущее старайтесь использовать или стандартные протоколы (Modbus), или нормальный человеческий ASCII. Окупится сторицей при наладке и эксплуатации.
Как-то писал модуль связи с кетайской системой контроля доступа: таким продвинутым домофоном с временными зонами, логами, группами пользователей и сканером отпечатков пальцев. Протокол там включал от 10 до 16 полей данных, среди которых были перемешаны big-endian integers, BCD, ASCII integers, нигические константы и контрольные суммы. Плюс машина состояний, по которой порядок выполнения комманд тоже имел свои особенности. Плюс документация на китайском диалекте английского. В общем проклинал я разработчика долго и со страстью и с тех пор не экономлю на байтах протокола.

0

@stt

Так ведь в приведенном протоколе обмен как раз символами ASCII и происходит.

0

@oski12345

Всем большое спасибо, теперь вроде уложилось. Если я так понял, то получается следующее:
1) Команда чтения состояния. Запрос занимает 6 байт. Ответ 12 байт;
2) Команда чтения задан. напр. и напр. отс. Запрос занимает 6 байт. Ответ 12 байт;
3) команда управления. Запрос занимает 14 байт. Ответ 4 байта;
4) Команда задания напряжения отсечки. Запрос занимает 14 байт. Ответ 4 байта.

0

@stt

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

0

@oski12345

спасибо, у меня по той же теме ещё вопрос: допустим пришла в контроллер команда управления устройством, я её как то собрал и запихнул в символьный массив: som[14]=$(27)(30)(0)(0)(0)(0C544)(0x0D). Как мне теперь вычленить из него подстроку (0C544) и преобразовать в шестнадцатеричное число 0х0C544.
Если бы стояла задача вычленить подстроку из десятичных символов и преобразовать в десятичное число(допустим 50500 в десятичное). Я бы наверно создал второй символьный массив размерностью 5 символов mas[5] и посимвольно присвоив его элементам соответствующие элементы принятой команды mas[0]=som[9]; mas[1]=som[10];..mas[4]=som[13]; функцией c= atoi(mas); преобразовал его в целое десятичное число, правильно ли это.. и как быть с шестнадцатеричным..

0

@stt

Да в общем, просто:
1. Убеждаешься, что первый байт является байтом начала посылки.
2. Убеждаешься, что посылка адресована именно этому модулю.
3. Включаешь счетчик принятых символов. Его переполнение укажет на ошибку кадра.
4. Декодируешь код команды, в зависимости от него обрабатываешь посылку.
Выполняешь начальные пункты. Сравниваешь принятый байт с $0D. Если не равен- вычитаешь (в данном случае) из принятого кода $37. Если получилось отрицательное число, то принятый символ < чем $A, -> нужно вычитать $30. В итоге получаешь двоичное представление принятого числового символа. Т.е., если после вычитания $30 осталась двойка, то и символ был "2". Короче, после того, как МК принял решение, что принятая последовательность адресована ему, расшифровал код команды и т.п., сравниваешь принятый байт с $0D и, если не равен, вычитаешь сначала $37. Если получилось отрицательное число, вычитаешь из принятого $30. Если остаток отличен от нуля- сохраняешь где нибудь значение, берешь следующее и т.д., пока не встретишь $0D или не переполнится счетчик принимаемых байтов декодированной команды. Получил признак конца посылки- делаешь преобразование DEC2BIN (процедуры есть и на ассме, а уж на Си- и подавно) и работаешь уже с двоичным представлением. Как-то так.

0

@oski12345

я наверно что то не так понял.., мне кажется надо из принятого кода вычитать первоначально не $37 а $39, чтобы убедиться что принятый символ < чем $A, и далее если результат <=0 то вычитать из принятого $30, а если >0 вычитать $37..
И ещё один вопрос.. Насколько я понимаю ответ на команду передаётся в несколько байтов без пауз друг за другом, это куча времени, а у меня там куча прерываний за это время может успеть придти..как быть в этом случае.. или там(между байтами одного ответа) всё таки можно вводить временные паузы..

0

@stt

Да, ошибся. Ну, тогда уж сначала вычитать даже не $37, а $3А, п.ч. $39("9")- $37>0.
Если используешь прерывания, то само событие происходит не по приему каждого бита, а когда собрался весь байт (Rx Complete). Считать его и пихнуть в буфер дело нескольких тактов. А чтоб не терять остальные прерывания, обработчики пишутся максимально короткими.
Вообще, вот статья: http://iosyitistromyss.ru/avr-uchebnyj- ... -uart.html

0

@oski12345

да, извините за глупый вопрос, я ступил..

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

0

@Stiit.mi

Очередь команд спасет отца русской демократии. То есть мы очень быстро разбираем пакет, определяем, что за команда, кладем команду в очередь и ждем другого пакета. В это время неторопливо обработчик команд вытаскивает команды по одной и обрабатывает.

Можно предусмотреть приоритеты команд - некоторые критичные команды сразу обрабатывать, не кладя в очередь. Например "ааа, блин, погасить все нафиг!!!".

А вообще, зачем задержка перед ответом? Есть ответ - пулим его в usart, там пусть комп разгребает.

В принципе, можно преобразовать протокол так, что до получения ответа комп не присылает никаких других команд (типа AT-общение с модемом).

0