Прошивки CleanFlight/BetaFlight для полетников
Столкнулся со странным поведением пк SPRF3EVO (оригинал, прошивка BF 3.1.6) - если долго лежит на столе включенный, самопроизвольно переходит в DFU режим О_о. Тестировал вибрации моторов, квадрик лежал на столе включенным минут 15, я отошел ненадолго и когда вернулся, он уже не отвечал на команды и при подключении шнурком к компу был в DFU моде. После передергивания батареи вернулся в нормальный режим. И потом еще несколько раз наблюдал, как мозг уходит сам в DFU режим. Но четкой последовательности действий для воспроизведения бага пока выявить не удалось.
У меня такое было на миники… я припаивал провода к буут контактам и они в месте пайки коротили… еле заметно…
Вопрос немного не по теме: есть мозг на основе f1, пишут это naze32 под коллекторные моторчики (мозг для микроквадрика). У него родной приемник под FrSky. ТАк как у меня RadioLink at9 ,я родной приемыш спаял и в коробку, а на его место впаял r6dsm. Теперь вопрос, не требует ли naze случайно инвертора для подключения радиолинковского s-bus? Не выходит их подружить, конфигуратор клинфлай не видит приемник. Дорожка s-bus подписана "S-bus - " и идет прямо в tx пин uart2 (угловой пин, 12 номер вроде). rx просто сидит на низком напряжении через делитель.
Если что, аппа приемыш видит (показывает rssi), квадрик это eachine x73.
Или вопрос тут не в тему и лучше в общей ветке про 250 спросить?
у меня на мелком на uart3 в настройках включен serial rx
на uart3 в настройках включен serial rx
Вроде как на f1 недоступен uart3. rx serial включен на uart2, на uart1 msp висит.
да, у меня F3 наверное
Посмотрите не уплывает ли напряжение питания. Если с питанием Ок, то значит от перегрева и это плохо.
Проверил, напряжение стабильно, перегрева тоже нет.
У меня такое было на миники… я припаивал провода к буут контактам и они в месте пайки коротили… еле заметно…
Контакты бута девственно чистые и залиты лаком.
Проблему удалось побороть программным костылем.
void serialEvaluateNonMspData(serialPort_t *serialPort, uint8_t receivedChar)
{
#ifndef USE_CLI
UNUSED(serialPort);
#else
if (receivedChar == ‘#’) {
cliEnter(serialPort);
}
#endif
if (receivedChar == serialConfig->reboot_character) {
//systemResetToBootloader();
}
}
По не до конца выясненной причине во время работы в один из портов случайным образом приходил символ, который BF рассматривает как команду перехода в DFU 😃😃
Пришлось в коде закоментировать вызов systemResetToBootloader().
Получается, что пк можно заставить перейти в DFU только одним символом, отправленным в serial-порт с MSP . Судя по всему, это нужо для прошивки контроллера через конфигуратор (когда переключатель “No reboot sequence” неактивен) и все.
Судя по этому куску кода:
static void taskHandleSerial(timeUs_t currentTimeUs)
{
UNUSED(currentTimeUs);
#ifdef USE_CLI
// in cli mode, all serial stuff goes to here. enter cli mode by sending #
if (cliMode) {
cliProcess();
return;
}
#endif
mspSerialProcess(ARMING_FLAG(ARMED) ? MSP_SKIP_NON_MSP_DATA : MSP_EVALUATE_NON_MSP_DATA, mspFcProcessCommand);
}
после арминга эта функция выключается, так что в полете самопроизвольная перезагрузка в DFU врядли возможна.
P.S. Больше 4 часов убил на это. Нельзя так просто взять и прошить betaflight 😆
Костыль, хорошо. Но тогда вопрос остаётся открытым: откуда приходит этот символ на перехода в режим DFU?!
Методом тыка я обнаружил, что баг всплывает при включенном softserial. У меня на softserial1 подключена minimOSD, а на softserial2 телеметрия smartport. Для osd порт конечно же работает в режиме MSP. Вот только есть одна странность - отключение osd и выключение softserial1 не убирает баг, как это можно было бы предположить. Зато баг пропадает, при выключении телеметрии SmartPort, хотя смартпорт не использует msp 😵 Магия.
Так же обнаружил еще один баг, косвенно связанный с softserial - при включенной функции softserial (сами порты могут быть даже не активны), не работает нормально blheli passthrough. При подключении конфигуратора blheli определяются не все ESC, причем случайным образом. Может не определиться ESC1, а при следующем подключении может не определиться ESC2 и 4, ну и т.д. Все вместе никогда не определяются. Но стоит выключить в настройках softserial, как все esc определяются отлично и с первого раза.
Короче, softserial в BF крайне кривой, по крайней мере для F3 контроллеров. На старенькой Naze32 rev.5 все работало отлично, только dshot она не тянет. Вот скоро придет BlueJayF4, потестирую на нем.
Короче, softserial в BF крайне кривой, по крайней мере для F3 контроллеров
А у вас какая версия BF то? В 3.1.6 были изменения насчет softserial. У меня есть BlueJayF4 могу на нем погонять.
А куда у Вас 3 UART порта используется на Ф3? Зачем SoftSerial включать. Я так думаю что вся магия из-за большой нагрузки проца при влюченном SoftSerial.
На последней прошивке БФ использую DSHOT600 SBUS S.Port OSD на LUX RACE F3 и нет проблем.
Закиньте issue на гитхаб, разрабы помогут раскопать корни…
А у вас какая версия BF то? В 3.1.6 были изменения насчет softserial. У меня есть BlueJayF4 могу на нем погонять.
Да, 3.1.6. Если не трудно, проверьте как работает blheli passthrough при включенном softserial и при выключенном, есть ли разница какая-либо.
А куда у Вас 3 UART порта используется на Ф3? Зачем SoftSerial включать.
На последней прошивке БФ использую DSHOT600 SBUS S.Port OSD на LUX RACE F3 и нет проблем.
UART1 - SmartAudio для настройки передатчика TBS Unify Pro (у меня рама не позволяет получить доступ к кнопке настройки)
UART2 - RX Serial для S.BUS
UART3 - MSP Bluetooth (можно без провода даже прошивку регулей обновлять)
SOFTSERIAL1 - MSP OSD (раньше OSD стояла на UART1, но SmartAudio не хотел работать с софтсериал, пришлось поменять местами)
SOFTSERIAL2 - телеметрия SmartPort
Загрузка проца не превышает 49%
Такую сложную конфигурацию я использую для того, что бы настраивать в коптере абслюлютно всё без единого провода. Через таранис настраивается почти все необходимое: пиды, рейты, частотный диапазон и канал передатчика + мощность передатчика. Ну и bluetooth для всего остального. Но даже если пожертвовать bluetooth, то все равно 1 softserial нужен. А отказываться от возможности настраивать основное с тараниса я 100% не буду.
Я так думаю что вся магия из-за большой нагрузки проца при влюченном SoftSerial.
Ну во первых, загрузка проца не большая. В пределах допустимого. Во вторых, при правильной организации планировщика задач, такая загрузка цпу не должна отражаться на работоспособности. Опять же, на назе32 работали нормально оба softserial.
А я бы по другому распределил. Все таки лучше ОСД на железный порт повесить. А вот СмартАудио как раз на СофтСериал, ведь им редко пользуетесь. Только когда надо перестроить передатчик, а на ОСД всегда данные передаются.
Да и Bluetooth лишнее. В полёте не нужна, а вес и железный порт отнимает. Проще его тоже на СофтСериал перенести и вывести разъём - нужно вставил модуль, полетел - убрал.
Я бы так распределил:
UART1 - S.Port
UART2 - OSD
UART3 - SBUS
SoftSerial1 - SmartAudio
SoftSerial2 - Bluetooth
Если бы был GPS то так:
UART1 - GPS
UART2 - OSD
UART3 - SBUS
SoftSerial1 - SmartAudio
SoftSerial2 - S.Port
Все таки лучше использовать железные порты там где большой поток данных.
А еще вроде рекомендуют не использовать МСП на более чем двух портах.
А еще вроде рекомендуют не использовать МСП на более чем двух портах.
Я одно время не мог понять почему я не могу включить на 2-х портах MSP на мозге LUX RACE. У него USB отдельно и всегда включено MSP и на двух других портах не мог включить. Потом вычитал что MSP должен быть один и один на USB.
А я бы по другому распределил. Все таки лучше ОСД на железный порт повесить. А вот СмартАудио как раз на СофтСериал, ведь им редко пользуетесь. Только когда надо перестроить передатчик, а на ОСД всегда данные передаются.
Да и Bluetooth лишнее. В полёте не нужна, а вес и железный порт отнимает. Проще его тоже на СофтСериал перенести и вывести разъём - нужно вставил модуль, полетел - убрал.
Я бы так распределил:
UART1 - S.Port
UART2 - OSD
UART3 - SBUS
SoftSerial1 - SmartAudio
SoftSerial2 - Bluetooth
Если бы был GPS то так:
UART1 - GPS
UART2 - OSD
UART3 - SBUS
SoftSerial1 - SmartAudio
SoftSerial2 - S.Port
Все таки лучше использовать железные порты там где большой поток данных.
Как я уже писал, СмартАудио заработало только на железном порту,да и в вики бетафлай написано подключать к железному порту. Блютус висит на uart3 не просто так, а потому что в sprf3evo uart3 работает только с 3.3v сигналами. Подключение туда например OSD (у которой TTL-уровни) может теоретически сжечь порт. Из железных портов остается только uart2 - само собой для s.bus.
Софтовый костыль пока работает нормально. На BF 3.2 все точно так же, но она пока еще сырая и может ближе к релизу ситуация изменится.
А вы osd в качестве средства настройки пользуетесь? Видимо, нет, иначе, зачем вам BT. Если так, можно расшарить BT и OSD на один порт, к OSD вести только TX
Народ что случилось с конфигуратором betaflight ? Его удалили из Гугла а скачанный не работает . Конфигуратор Cleanflight не читает прошивку BF
а скачанный не работает .
а откуда качали?
отсюда - github.com/betaflight/betaflight-configurator ?
Народ что случилось с конфигуратором betaflight ? Его удалили из Гугла
Видимо, заливают новый релиз 1.9.4 - он вышел 3 часа назад.
скачанный не работает
Всё прекрасно работает- только что проверил.
2016.03.09 - 1.9.4 - BetaFlight
Fix broken backup/restore
changed suggested filename for backup to include craft name,
Я что то не так делаю? не могу найти конфигуратор бетафлай в магазине гугл-пришлось ставить файлы в режиме разработчика
его, что убрали из магазина?
блэкбокс например есть…??
Упс…не читал выше, я не один!
вобщем, ставьте файлы с гитхаба в режиме разработчика если что!