roboforum.ru

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

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

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

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

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

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

да, вызывать команды из своего приложения типа 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 сильно пересекается с ним

да, так и сделано в 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)();
      }
  }
  ...
}

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

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

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