Прошивки CleanFlight/BetaFlight для полетников
Вот видео в тему для экономии юартов и проводов:
Он пока сырой как болото весной - телеметрия лагает жутко, данных на экранах BF LUA вообще хрен дождёшься.
Я уже писал в соседней теме, что полагаю весьма странной идеей - пихать управление, телеметрию, LUA и RSSI в ПОЛУДУПЛЕКСНЫЙ (однопроводный) протокол. Это ж как участок “реверсивного движения” при ремонте дороги - “пробки” обеспечены по определению. Кой смысл было упираться в однопроводный протокол вместо двухпроводного асинхронного (например, вывод SBUS в качестве TX и SPort в качестве RX) - мне непонятною
Кой смысл было упираться в однопроводный протокол вместо двухпроводного асинхронного (например, вывод SBUS в качестве TX и SPort в качестве RX)
допилят все. в этом плане бетафлайт молорики.
допилят все.
Чем раньше сообразят перейти на дуплекс - тем скорее допилят. 😃 Я правда никак не могу понять смысла “упёртости” в 1-проводку, это ж “сам себе злобный Буратино”. 😃
Разработчик в слаке ответил, что на днях уже будет улучшение в протоколе.
Чем раньше сообразят перейти на дуплекс - тем скорее допилят. 😃 Я правда никак не могу понять смысла “упёртости” в 1-проводку, это ж “сам себе злобный Буратино”. 😃
на каждом полетнике уже есть СБАС. Или ППМ.
И их “однопроводные” можно использовать.
если сожрать “живой” уарт - нафиг оно все нужно?
Что-то вы дюже загадочное написали 😁
1)
если сожрать “живой” уарт - нафиг оно все нужно?
SBUS - это и так “живой” UART, причём аппаратный, а не софтовый - на некоторых полётниках этот же UART “продублирован” отдельными RX и TX (на F4, как правило, разница этих “пятаков” в наличии инвертора на пятаке SBUS) И, хотя занят там только RX, порт оказывается занят целиком. Так что для FPort можно было бы использовать тот же “SBUSовский” UART “по полной”, раз уж FPort в том числе заменяет SBUS.
2) По поводу использования SBUS+SPort - я больше имел в виду приёмник (XSR), где изначально не было предусмотренно асинхронного выходного порта.
3)
И их “однопроводные” можно использовать.
Убогость “однопроводности” и проблемы, вылезающие из этой убогости, я уже описал выше - после того как натолкнулся на них на практике.
Тут проблема еще может быть в том, что радиоканал имеет свои ограничения, и полный дуплекс тут не катит, что выглядит вполне логично. Посмотреть бы, как вещают сейчас sbus в одну сторону и s.port в другую, точно ли это может происходить одновременно?
Убогость “однопроводности” и проблемы, вылезающие из этой убогости, я уже описал выше - после того как натолкнулся на них на практике.
Да это бред какой-то. Между аппой и приёмником полудуплексный канал, какой смысл между приёмником и FC делать дуплекс?
после краша (предположительно) стал греться проц на omnibus f4 v1, но только при подключении по usb. При этом гиро уплывает во все стороны сразу же в конфгураторе. Просто приложив палец в качестве охлаждения - гиро возвращается на место. отпускаю - уплывает)). ПК видится в конфигураторе нормально. Но все это только при usb подключении. Ппри подаче 5в от pdb все в порядке, ничего не греется. Есть идеи?
и еще интереснее: подключаю просто 5 в по usb - не греется. Греется только когда определяется как устройство компом. Чудеса.
Да это бред какой-то. Между аппой и приёмником полудуплексный канал, какой смысл между приёмником и FC делать дуплекс?
А при чем тут канал между аппой и приемником? Я сравниваю работу общеиспользуемой связки из sbus/ppm и s.port с “интегральным” протоколом FPort и вижу во втором случае лаги по направлению от полетника к приёмнику (телеметрия и данные по lua-запросам). То ли авторы сильно косякнули с приоритетами прямой и обратной передачи то ли дело в скорости обмена - не знаю. Но если для задачи двунаправленной передачи данных можно использовать полнодуплексный протокол - кой смысл закрывать одну из створок двери у себя же перед носом и использовать полудуплекс? Один фиг второй провод порта никто другой использовать не сможет - к чему эта “экономия”? Разве что вытаскивать FPort на softserial и выводить через моторный пин - тогда да, экономится аппаратный uart. Но вешать канал радиоуправления на softserial - это для экстремалов. 😃
А при чем тут канал между аппой и приемником?
Канал между аппой и приемником - это, по сути, связь между двумя модемами. Stm32 в приемнике просто, грубо говоря, передает данные, пришедшие через этот модем (с конверсией форматов, разумеется) дальше в полетный контроллер. Ну и наоборот для телеметрии. Если модем работает в полудуплексе, то нет никакого смысла как-то ускорять и оптимизировать передачу на участке между stm32 и полетником. А дуплекс на радиоканале с одновременным приемом и передачей организовать сложнее, они просто будут мешать друг другу, надо усложнять конструкцию, и антенна всего одна.
К тому же этот модем, скорее всего, имеет скорость передачи гораздо ниже максимально допустимой скорости UART. У них в прошивке под fport сейчас наверняка просто какие-то косяки наблюдаются, которые мешают корректной работе. Поправят и все будет хорошо.
Кой смысл было упираться в однопроводный протокол вместо двухпроводного асинхронного
к чему эта “экономия”?
Ты реально не понимаешь? 😆 один провод против двух
Убогость “однопроводности” и проблемы, вылезающие из этой убогости, я уже описал выше
Вот это ты дал, “полудуплексу не хватает скорости” 😆
Ещё раз предлагаю не впутывать сюда радиоканал. 😃
Смотрите:
- Есть асинхронно работающие (аж по двум разным uart) sbus и s.port - каждый по одному проводу. Sbus только в одном направлении, s.port в обоих в полудуплексе - но основной объём данных у него идёт в направлении, обратном sbus.Все работает быстро - и туда и обратно.
- FPort объединяет оба канала из пункта 1 (плюс rssi, но это уже мелочи) - и в результате дает лаги в “обратном” направлении (телеметрия). При этом “второй провод” того же uart, на котором висит FPort, этим протоколом не используется и не может быть использован никем другим (так как uart аппаратный - не ремапится и не делится между несколькими протоколами).
Вывод - на хрена было “вставать на одну ногу”? 😉 Uart сэкономили - отлично. А вот один проводок (3 от приемника вместо 4) явно не стоит лагов.
Ещё раз предлагаю не впутывать сюда радиоканал.
Да причем тут радиоканал 😆 решить что fport’у не хватает скорости из за однонаправленного режима работы маразм. Вайфайное оборудование работает в полудуплексе(ну кроме совсем последних версий), езернет может работать в полудуплексе. А там мегабайтами скорость измеряется 😉
и в результате дает лаги в “обратном” направлении (телеметрия)
это временно. не будет никаких тормозов. об этом речь. о бете и релизе…
Вывод - на хрена было “вставать на одну ногу”
Я же открыл тебе глаза, один провод 😆
не будет никаких тормозов.
Конечно не будет )
Тем не менее логика в идеи fullduplex есть, и оно будет лучше и быстрее чем просто один провод.
То что исправят сомнений нет, и это удобно. Тем не менее приоретет будет за управлением, и в определенные моменты телеметрия будет затыкаться, в худшем случае и управление.
У нас же водопровод и канализация не по одной трубе… 😃
Скоро приёмник подключат через SPI, там уж точно дуплекса не будет. МУХАХА!
Тем не менее приоретет будет за управлением, и в определенные моменты телеметрия будет затыкаться, в худшем случае и управление.
О чём с самого начала и говорил. Но некоторым в силу “дюже образования” это сложно понять. 😃
Скоро приёмник подключат через SPI
Было бы неплохо. Правда, высокая скорость передачи потребует нормальной экранировки линии данных - уже абы как проводками не соединишь. И это будет относительно нишевой продукт, способный работать лишь напрямую с контроллером, и требующий от контроллера соответствующей аппаратной и программной поддержки.
Хотя… пошёл же DSHOT в массы - может, и здесь так получится.
Скоро приёмник подключат через SPI, там уж точно дуплекса не будет. МУХАХА!
Помимо спи, там ещё нужно управлять антеннами, то есть минимум 8 проводов.
Кстати насчёт spi, в последней бете беты добавили:
3. Added FrSky X SPI RX protocol
Кто знает о чем речь? Вроде не слышал о приемниках фриски с spi