Управление с телеметрией по serial

void HC_12(){
`Serial2.print(F(“AT”)); // отправка запроса на проверку
здесь наверно надо не большой делей
if(Serial2.available() == 0){return;}
while (Serial2.available()) { //читаем сериал 2
Serial.print(Serial2.read());} //пишем в сериал
}

1 лайк

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

да, наконец-то я разобрался с этим… оказывается после отправки каждой (!) АТ команды нужна задержка не менее 40мс, иначе модуль вернет ERROR. Также она нужна перед подачей HIGH на SET, иначе последняя команда потеряется. В гайдах и даташите не заметил этой информации. Там написано что перед отправкой команд такая задержка нужна, но эта инфа идет сразу после рассказа про LOW на пин SET и кажется, что имеется ввиду необходимость один раз выдержать 40мс после подачи LOW. Забавненько получилось

Upd. вынес настройку в ф-ию с передачей Serial по ссылке, при желании можно дополнить другими параметрами и проверками их на соответствие. Сейчас функция будет пытаться сконфижить модуль только если не удалось пообщаться с ним на 11520. Функция собирает простенький лог выполнения и возвращает его в результате выполнения.

String hc12setup (HardwareSerial *serial, uint8_t set) {

  String log = "Function hc12setup (pin " + String(set) + " might been connected to HC-12 SET pad)";

  pinMode(set, OUTPUT); // конфигурация пина активации режима AT
  serial -> begin(115200); // поднятие порта на 115200
  digitalWrite(set, LOW); // активация режима AT команд

  // далее идет отправка AT команд в модуль и получение результата
  // по datasheet так и не стало понятно, перед отправкой нужны задержки 40мс или после, или между
  // поэтому используются задержки по 40мс между каждыми взаимодействиями с модулем

  // отправка запроса на проверку подключения
  delay(40);
  serial -> print("AT\r");
  delay(40);

  if (serial -> readString().indexOf("OK") != -1) {

    log += "\r\nSucessfully connected on 115200"; // подключение удалось

    serial -> print("AT+RX\r"); // запрос конфигурации
    delay(40);
    log += "\r\n" + Serial1.readString();

  } else {

    log += "\r\n Failed to connect on 115200, trying configurate on 9600"; // походу подключен новый модуль, попытка настроить на 9600
    
    serial -> end(); // закрытие порта
    serial -> begin(9600); // поднятие порта на стандартнх 9600

    delay(40);
    serial -> print("AT+B115200\r"); // отправка конфигурации - скорость порта
    delay(40);
    serial -> print("AT+FU1\r"); // отправка конфигурации - режим
    delay(40);
    serial -> print("AT+P1\r"); // отправка конфигурации - мощность
    delay(40);

    digitalWrite(set, HIGH);  // выход из режима AT команд
    delay(80); // задержка для применения настроек модулем по datasheet 80мс

    serial -> flush(); // очистка буфера порта (там результат применения конфигов, возможно прочий мусор)
    serial -> end(); // закрытие порта
    serial -> begin(115200); // поднятие порта на вожделенных 115200
    
    digitalWrite(set, LOW); // запуск режима AT команд
    delay(40);
    serial -> print("AT\r"); // отправка запроса на проверку подключения
    delay(40);

    if (serial -> readString().indexOf("OK") != -1) {

      log += "\r\nSucessfully connected on 115200 after configurate"; // подключение после настройки удалось

      serial -> print("AT+RX\r"); // запрос конфигурации
      delay(40);
      log += "\r\n" + serial -> readString(); // вывод конфигурации

    } else log += "\r\nFailed to configure HC-12 wia AT commands, check physical connection"; // попытка настройки не удалась - проверяем провода, подаем питание закоротив SET на GND (отключив от Arduino!!!)
  
  }

  // serial -> print("AT+DEFAULT\r"); delay(40); // сброс модуля на заводские (еси нужно потестить функцию)

  digitalWrite(set, HIGH);  // выход из режима AT команд

  return log;

}

// при использовании передавать Serial по ссылке
Serial.println(hc12setup(&Serial1, 2));

Ждать потерянные байты - это одно, а складывать в память мусор - другое.
Впрочем, дело ваше.

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

С размерностью, передаваемой сразу следом после стартового байта (динамический размер пакета) могут уже быть проблемы, если сами данные о размерности утеряются, то следующий принятый байт может быть воспринят как размерность, а там “псевдослучайное” значение, т.е. тоже собираем мусор. Шанс такого события примерно равен шансу утраты завершающего байта, как по мне.

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

Кстати я наконец-то поймал рассинхрон по байтам при работе кода из первого поста. Отключал-подавал питание на передающем модуле и это случилось. Теперь необходимость использования старт байта для меня даже на практике очевидна

поинтересуюсь, чем mavlink не устроил?

у меня както так посылки шлюцца

если принялось #, а потом не #, в разбор ничего не идёт
ну а если ##, тогда следом читается ID, если он не совпадает с ID приемника, в разбор дальше опять же ничего не идёт.
И т.д.
На любом этапе, если посылка не по шаблону выше - она отбрасывается

Это протокол, если от приемника не требуется подтверждения.
Иногда удобнее конец пакета обозначать другим символом/символами, например $, или даже $$, тогда понятно, что пропускать надо всё, до $

1 лайк

Как то сурово всё, для гексапода :slight_smile:

И это только точка - точка. И без подтверждений.)

$$ завсегда лучше, чем просто $. А ежели б еще $$$…

1 лайк

А сервоприводов сколько будет?

можно так:

  1. ждем старт-байт
  2. принимаем байты, размер посылки фиксированный
    А. время между байтами больше 3? (например) ГоуТу 1.
  3. CRC совпала? выполнить команду
  4. ГоуТу 1.

Если старт-байт может встречаться в данных, то добавить еще ожидание тишины (те паузы между байтами > 4 байта и более, например).

1 лайк

18 штук

1 лайк

Делал на 17, HC-05 и только про мини. Загрузка скетчей по воздуху.


ролик 11
С устойчивостью промахнулся, надо было переделывать, но не стал :slight_smile:

1 лайк

Круто очень! После такого, использование меги мною выглядит как из пушки по воробьям )) Получается, bluetooth к Serial, т.е. проброс напрямую и для связи и для прошивки. И почти все выводы прохи задействованы для выдачи ШИМ. Кстати, если 1 остался, можно использовать для ws2811

Мне очень интересно, как вы реализовали выдачу ШИМ, библиотекой или сами прерывания по таймеру писали, и насколько много это занимает ресурса камня.

Если выдавать ШИМ апаратно таймером то ресурсы МК тратятся только на инициализацию процесса. Это несколько микросекунд.

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

1 лайк

так выводов с аппаратным шим далеко не 17 на прохе…

Есть такая штука :slight_smile: Servo.h