roboforum.ru

В рамках разработки проекта "OR Hexapod Control (Qt + GCC + SSC32)"
столкнулся с тем что было бы удобно использовать готовую библиотеку управления контролером с прошивкой ORFA.

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

Репозитарий проекта https://github.com/setar/orfa-lib
по вопросам прав для внесения своих модификаций обращаться ко мне.

Добавлено спустя 3 часа 20 минут 36 секунд:
Все свои наработки причесал и выложил.
Но я не программер, требуется помощь.

У кого вообще есть потребность в использовании такой библиотеки ?

Сергей, не понял а библиотека для чего?
Для того что бы не писать текстовую строку управления?

Писать ерунда, вот ответы разбирать...

Т.е. Цель написать парсер для вывода из ORFA?

да, вызывать команды из своего приложения типа comm_update_servos()
или comm_check_busy () , comm_get_adc ().

В общем цель - абстрагироваться от вопросов протокола передачи команд и обработки результатов.

P.S. это не просто передача команд и чтение из порта, тут все сложнее.
я когда шестинога делал столкнулся с тем что когда инверсная кинеметика считается на компьютере и передаются команды управления по bluetooth то для плавности движения поток управления весьма большой, требуется аппаратный контроль потока (без него буфер накапливается и на контроллер приходят команды с задержкой 5-10 сек).
Но самое фиговое это ожидание ответа от аналоговых датчиков, там задержки существенные, если ждать ответа сразу после запроса то все остальное тупит от этих таймаутов. Пришлось делать асинхронный обмен - пишем команды отдельно, и ответы отдельно разбираем, не ожидая их.
мой мозг умер на разборе регулярных выражений потока ответов микроконтроллера ...
мне кажется что я не один уперся в необходимость асинхронного разбора вывода, собственно поэтому решил сделать все правильно.

Добавлено спустя 1 час 15 секунд:
народ, кто на GCC программирует, покажите пример.

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

Код: Выделить всё • Развернуть

+
.
ERR09 in P cmd
ERR09 in P cmd
F0:1.49
PinModeF0=ADC
PinModeF5=ADC 

хочется парсить некий буфер char[255] buf; на предмет наличия этих сообщений и заполнения статусной переменной
struct orfa_result {
uint8_t status;
uint8_t length;
char data[255];
float adc[8];
}

Вероятно сюда нужно некую постоянно увеличивающуюся переменную добавить, с "тиком", чтобы знать что было обновление одного из значений.
буду рад хотя бы примерам аналогичного парсинга.

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

например

Добавлено спустя 1 минуту 29 секунд:
вообще в планах ввести совместимость с SSC32 и формат ответа ORFA сильно пересекается с ним

ну я конечно не знаю на сколько это актуально в хоббийстве, но имхо как-то так:
пакет:
{[start sequence] [addr] [legth] [cmd] [data] [CRC] [end sequence]}
формат - не читаемый, просто байты данных..

по приходу условия начала пакета (0xff 0xff \ 0xfe 0xfe старт\стоп например) читаем длину пакета, ложим все в буфер, сверяем длину, условие стопа, CRC - парсим.. если ошибки при передаче - парсить даже не придется.. если у нас только 2 устройства - адрес отмирает, хотя я бы гонял все равно.. потом можно просто перейти на более сложную систему..

да, так и сделано в SPI но ответ ORFA как и SSC32 к сожалению уже дан и от текстовый, практически не формализованый
вот пример фрагмента буфера :
09 in P cmd+++++……+++++
F0:1.49
F0:1.49
F0:1.49+++++...
ERR09 in P cm

Добавлено спустя 8 минут 18 секунд:
первое приближение

Код: Выделить всё • Развернуть

typedef struct {
  char *pattern;
  void (*func)(void);
} action;

static action **act=(
(
&("ERR09 in P cmd",err09),
&("F0:1.49",f0149),
...
...
NULL
);

void main(void) {
  ...
  for (p=buf; *p; p++) {
    for (b=act; *b; b++) {
      if (0==strncmp(*b->pattern,p,strlen(*b->pattern))) {
        (*b->func)();
      }
  }
  ...
}

ну так я и сказал, простите за офф, иначе - нужно переделывать ORFA. а зачем обязательна поддержка SSC32 мне тоже не ясно...

ПС я потому и не участвую в разработке орфы, ибо такой подход мне не по душе.. конвертить туда сюда данные.. в пустую..

ППС есть желание делать свои модули.. как более "серьезный" уровень, но пока нет особо толковых соратников. один по времени не потяну однозначно..

поддержка SSC32 для унификации, это как Arduino - распространенный западный стандарт.

Ты уже смотрел старую-старую liborfa? А в еще более старом pyor был асинхронный ввод-вывод. Только вот что-то оно не нужно.

(Кстати в F1-DS хочу сделать полный протокол SSC-32).

она вроде на питоне? смотрю
а асинхронность очень нужна, чуть позже концепцию нарисую

Это pyor на питоне. Там был аж отдельный тред с парсером, который скидывал все в queue.
А liborfa это чисто сишная библиотека, но я написал биндинг к питону. В ней я выкинул эти навороты за ненадобностью, ОС и так предоставляет хороший буфер.

А т.к. i2c-шный протокол у нас чисто синхронный, то вся эта асинхронность оказалась не востребована.
Не, у меня можно кинуть несколько команд чтения/записи не разбирая вход.

Код: Выделить всё • Развернуть

#include <orfa/orfa.h>
void main()
{
struct orfadev *dev = orfa_open("/dev/rfcomm0", 115200);

orfa_write(dev, -1, (unit8_t[]){0, 1, 2, 3}, 4);
orfa_read(dev, -1, 5);

struct orfareply *reply = orfa_read_reply(dev);
free(reply); // ignore OR_WRITE

reply = orfa_read_reply(dev);

// doo somesing

free(reply);

orfa_close(&dev);
}

ОС предоставляет отличный буфер, он заполняется и выпуливается на паука мало того что просто с задержкой до 10 сек (просто поток команд генерится большой), но и даже после того как выключить и включить паука
Пока он не "пройдет" того что уже влито в него - ничего нового не воспримет.
Именно поэтому я буду отключать буферизацию (сильно уменьшать), и обработку ввода, вывода на контроллер, ввода / вывода управления и расчёта логики буду делать отдельными тредами, разумеется асинхронно.
Нужно же использовать многопоточность