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 лайк
Как то сурово всё, для гексапода 
И это только точка - точка. И без подтверждений.)
$$ завсегда лучше, чем просто $. А ежели б еще $$$…
1 лайк
А сервоприводов сколько будет?
можно так:
- ждем старт-байт
- принимаем байты, размер посылки фиксированный
А. время между байтами больше 3? (например) ГоуТу 1. - CRC совпала? выполнить команду
- ГоуТу 1.
Если старт-байт может встречаться в данных, то добавить еще ожидание тишины (те паузы между байтами > 4 байта и более, например).
1 лайк
18 штук
1 лайк
Делал на 17, HC-05 и только про мини. Загрузка скетчей по воздуху.
С устойчивостью промахнулся, надо было переделывать, но не стал
1 лайк
Круто очень! После такого, использование меги мною выглядит как из пушки по воробьям )) Получается, bluetooth к Serial, т.е. проброс напрямую и для связи и для прошивки. И почти все выводы прохи задействованы для выдачи ШИМ. Кстати, если 1 остался, можно использовать для ws2811
Мне очень интересно, как вы реализовали выдачу ШИМ, библиотекой или сами прерывания по таймеру писали, и насколько много это занимает ресурса камня.
Если выдавать ШИМ апаратно таймером то ресурсы МК тратятся только на инициализацию процесса. Это несколько микросекунд.
В библиотеке серво подправил число с 12 на 17. Тут меня ругали, в связи с возможной неустойчивостью работы библиотеки, но практика показала устойчивость.
1 лайк
так выводов с аппаратным шим далеко не 17 на прохе…
Есть такая штука Servo.h