roboforum.ru

[Vooon]

Нет, КА вполне честный:
В CET_COMMAND получаем 'C', переходим в состояние PARSE_CONFIG, выходим.
В PARSE_CONFIG вызывается другой КА (get_cmd_byte()) по его завершению выходим.

bool get_cmd_byte(char, *data, *error)
На первый вход читает старшую часть байта, и помещает его в *data, переключает состояние на прием второй части, возвращает 0.
Во второй вход читает младшую часть, побитное или результата с *data, результат помещается обратно в *data,
возвращает 1.

[=DeaD=]

Так, разобрался, прошивка состоит из 2 вложенных КА и 1 почти КА выполняющего команды.

[=DeaD=]

Кстати, а как в оригинальном девайсе - ответ в UART выплёвывается сразу по получении байта с i2c или из буфера?

[Vooon]

Буфер. В оригинальном девайсе собираются CDC пакеты для USB
И читает также пакет в буфер.

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

[Vooon]

Сильно дебажная версия нового шлюза http://hg.vehq.ru/i2c-parser/
Выкладываю для проверки работы I2C.

[=DeaD=]

Тестовый шлюз Vooon'а прошел проверку на работу с SRF08 по протоколу i2c - чтение версии, измерение расстояния, чтение датчика освещенности.

[blindman]

Все таки нафигачили кучу команд избыточных ?

[Vooon]

Весь список команд:

S<adr><data>[S<adr><data>[S...]]P
R<adr><reg>[<len>]
W<adr><reg><data>
C<freq>
L<adr>
V
# comment

При чем R/W только для удобства, парсер перегоняет в формат идентичный командам:

R —> S<adr+w><reg>S<adr+r><len>P
W —> S<adr+w><reg><data>P

Эту часть парсера можно легко отключить.

L — для установки адреса внутреннего ведомого;
С — для настройки частоты тактирования, по умолчанию 100 кГц.

V — показать версию прошивки
# — просто удобно, тем более что кода занимает не много, обрабатывается полностью парсером.

Добавлено спустя 15 минут 53 секунды:
Деиствие запись/чтение зависит от последнего бита адреса (как и в i2c)

Условно обозначу запись/чтение
<adr+w> в бинарном виде: xxxxxxx0
<adr+r> — xxxxxxx1

<adr>, <reg> и <len> записывается последовательностью из двух символов в шестнадцатеричной системе
до и после может быть любое число пробелов

<data> записывается аналогично адресу, есть альтернативный вариант: \<любой-символ>

Запись:
S<adr+w><data>

Чтение:
S<adr+r><len>

Для команды R <len> по умолчанию равен 1.

[=DeaD=]

Все таки нафигачили кучу команд избыточных ?

Избыточная по твоей терминологии тут вроде одна обобщенная команда S....P - она позволяет делать по i2c что угодно. Остальные вроде как ты и предлагал сделать?

[blindman]

Я предлагал 2 - запись и чтение. L, C, V - избыточны. Под них резервируем регистры, и используем чтение/запись

[=DeaD=]

L не может быть избыточна. Без неё не ясно куда стучаться.
C и V - может быть.

[Vooon]

Забыл указать команду X — сбросить шину, посути выполняет S 00 P.

Считаю что переносить С в регистр нельзя: иначе мы лишаемся возможности отделить програмный модуль Serial-to-I2C чтобы использовать его отдельно (например в малом модуле serial->i2c на какой-нибудь мелкой меге/тиньке) без использования части модуля ведомого. L в таком модуле может отсутствовать.

V удобна для проверки порта (есть кто? И если есть, то какой версии протокол?)
Можно сказать эквивалент AT

[=DeaD=]

На самом деле, как мне кажется, можно применить и тот и другой подходы. (можно оставить LCVX команды и сделать L необязательной, а можно сделать L обязательной и CVX сделать через i2c регистры). Всё это по причине того, что конвертер uart<->i2c это вообще говоря штука обособленная и пока мне не ясно почему оно обязательно должно быть через i2c-регистры

Поэтому если уж Vooon сделал пока так - можно так и оставить, если нет существенных противопоказаний.

[Vooon]

L и сейчас посылать не обязательно, адрес по умолчанию 0xAA

[=DeaD=]

Обязательно, адрес по умолчанию мог быть изменен, а программно модуль нельзя перегрузить. Или надо команду сброса программную...