Activity

Переделал приложение на основе идеи Buranov_P, за что ему большое спасибо!
Теперь периодичность вывода спектра на экран порядка 200мкСек * 164канала = 33 мСек, видно как циклически бегает по диапазону частота какого-то устройства (вероятно мышь на 2,4ГГц). Есть постоянно торчащие палки примерно одного уровня мощности сигнала. Вобщем - картинка стала вполне информативной и теперь не требуется никаких доп. настроек.

Оптимально - передавать по строкам.

А какие параметры строки(длина, кол-во стоп-битов)?

Строка принимается в буфер порта, быстро считывается в память, и начинает отрисовываться

Если я правильно понял, отрисовка спектра будет производится кусками размером определяемом кол-вом символов в строке?
P.S. Вы WinFormApplicatin используете?

Странно.
У меня отрисовка 2 каналов(10 бит разрешение) при 200 точках около 1 секунды.
Скорость не максимальная, 57600, без всякой оптимизации.

Я, честно говоря, уже не в первый раз натыкаюсь на невозможность обмена данными с компом на нормальной скорости. Одиночные байты пролетают без проблем(пробовал скорости до 2МБит.сек), но стоит запустить пакеты данных - тут же возникают тормоза или вовсе виснет комп. Причём я пробовал по крайней мере два варианта переходников: один на USB/USART на FS-ке, другой - BlueTooth модуль. К компам тоже подключал разным(по меньшей мере 3 варианта), но результат тот же.
Консультировался на Cyberforum.ru, там мне всяко-разно советовали, но существенного улучшения добиться так и не удалось.
Может проблема в алгоритме отрисовки? Я пытаюсь каждый канал отрисовывать в реальном времени(по приходу каждого значения RSSI с приёмника). Может нужно засовывать весь спектр в буфер, а потом отрисовывать из буфера? Или метод какой-то другой на форме использовать?

Ковырялся периодически во время отсутствия на форуме со своим вариантом спектроанализатора на А7105. Сначала воодушевился вариантом сделать монитор на дисплейчике от Nokia 3310(5510), разломал несколько библиотек под свои нужды, но в конце концов понял, что экран очень маленький и спектр можно будет увидеть только приблизительно. Покупать какой-либо другой дисплей покрупнее не захотелось и я решил написать приложение под Windows, которое будет отрисовывать пришедшие с приёмника А7105 по USART значения RSSI.
Ну, на стороне приёмника программа примитивнейшая: инициализация, ожидание команды на сканирование(ждём прихода символа ‘S’ по USART), цикл сканирования(переключается канал, пауза для установки частоты гетеродина, чтение значения из регистра RSSI, передача значения RSSI по USART), при выходе из цикла обнуляем номер канала.
С отрисовкой я провошкался довольно долго, но всё таки победил. Оказалось, что есть проблема в скорости приёма компом информации по USART. Опытным путём добился максимальной скорости 40 байт/сек и то при смене приоритета для приложения в диспетчере задач на “реального времени”. Это грустно. Но запуская сканирование несколько раз подряд спектр увидеть можно.
Если кому интересно поиграться, выложу приложение. Однако, в нём есть ряд ограничений, которые надо учитывать при использовании.

Те, которые упомянуты в исходнике прошивки?

Да, библиотеки для тех дисплеев, которые Вы использовали в данном проекте.

Большое спасибо за разъяснения. Жаль, но в моём случае (А7105) измерение RSSI происходит только по детектированию приёма полезного сигнала и само значение RSSI записывается в регистр только после окончания RX-State. Иными словами: читать RSSI можно, но, пока нет приёма сигнала, регистр не обновляется.
Вообще, информация по А7105 крайне скудная и неудобоваримая, не смотря на то, что чип этот довольно популярен.

Покопался в даташите и обнаружил, что был неправ. Есть режим измерения RSSI без приёма полезного сигнала. Китайцы обозвали его: Auto RSSI measurement for Background Power. А режим, который я описывал выше называется Auto RSSI measurement for TX Power.

Auto RSSI measurement for Background Power:

1. Set wanted FRXLO. Установка частоты гетеродина.
2. Set RSS= 1 (1Eh), FSARS= 1 (1Eh, 4MHz ADC clock). Биты конфигурации
3. Enable ARSSI= 1 (01h). Бит разрешения автоматического измерения RSSI
4. Send RX Strobe command. Переключение в состояние приёмника
5. MCU delays min. 140us.
6. Read digital RSSI value from ADC [7:0] (1Dh) to get background power.
7. Send other Strobe command to let A7105 exit RX mode.
   Думаю, что теперь я смогу сделать анализатор.
   P.S. Вы выложили проект для Меги, но я с Атмелами не дружу и хотел попросить, если возможно, выложите библиотеки для дисплеев отдельно.

Интересный проект. Я сейчас ковыряюсь с трансивером А7105 и хочу попробовать соорудить нечто подобное. В связи с этим имею вопрос: а что-таки ловится из эфира и с чем сравнивается для получения RSSI? Или по-другому: что есть тот полезный сигнал, с которым сравнивается входной шум?

Решил выложить картинку со своего лог. анализатора:

По-моему довольно наглядно.

Похоже я до сих пор пребывал в заблуждении. Действительно, посмотрел здесь: www.*************/blogs/view_entry/7574/

Прям стыдно стало за своё невежество…😦

Приветствую всех. Решил посмотреть анализатором РРМ-сигнал в своём передачтике(он у меня ещё v 1), который идёт с основной платы на ВЧ-блок. Был изрядно удивлён той трактовкой РРМ, которую зашили в передатчик турнигоделы в Китае. Итак, сигнал имеет следующие параметры:

• частота пачек - 50Гц(Т=20мСек);
• количество импульсов в пачке - 8;
• промежуток между импульсами - t=0,4мСек;
• а теперь самое интересное: длительность импульса: Тмин=0,6мСек, Тмакс=1,6мСек
  Я поначалу не поверил, начал крутить крутилки, щёлкать тумблеры, двигать стики. Результат не менялся. Я не мог понять как же при таком раскладе на приёмнике получаются нормальные сигналы на выходах? Потом понял: при измерении длительности импульса контроллер ВЧ-части меряет не непосредственную длительность импульса, а сумму длительности и промежутка! Тогда получается стандартный диапазон РРМ-сигнала: от 1мСек до 2мСек. Предполагаю, что сделано это ради обработки только одного прерывания (по спаду импульса) в контроллере ВЧ-части при подсчёте длит. импульса или в контроллере основной платы при формировании.
  Выходит, что Turnigy 9X - это не совсем просто…

Всем здрасьте.
У меня Турнига первой версии (V1). После замены потенциометра на правом стике на датчик Холла возникла необходимость перекалибровки стика. Я опробовал алгоритм описанный здесь: rcopen.com/forum/f4/topic139588/1540 и у меня ничего не вышло. Споткнулся уже на первом шаге алгоритма: “сдвигаем триммеры и удерживая их включаем аппу: наблюдаем заставку и цифры 0000 вверху.” У меня при включении со сдвинутыми триммерами на экране обычная заставка и на клавишу “+” реакции нет никакой. Триммеры пробовал сдвигать в разных направлениях и комбинациях. Результат - никакой реакции. Может в первых версиях не предусматривалось калибровки стиков? Подскажите кто знает, а то не хочется дополнительно схему с операционником городить чтобы стик отмасштабировать.

Я предположил, что люди собирающие конструкции в диапазоне 5.8ГГц могут снизойти до диапазона 2.4ГГц и дать дельный совет по моему вопросу.

Всех приветствую.
Последний месяц ковырялся с ресивером А7105, вернее с готовым модулем на его основе с кварцем. В качестве контроллера для управления и обработки принимаемой/передаваемой информации использовал STM32F103. На данном этапе имею готовый канал - MASTER-SLAVE в диапазоне 2.4ГГц с функцией “пробежки” по диапазону(frequency hopping).
Планирую приделать усилитель АР1110 для увеличение дальности передачи. Вопрос у меня в том, как организовать подключение антенны развязав вход приёмника и выход передатчика? В теории я понимаю, что нужно ставить трансформатор(balun) и ещё хорошо бы ключи, отключающие антенну от выхода передатчика и подключающие ко входу приёмника. Однако, мне кажется, что в современной аппе WiFi таких приблуд нет и ставят усилитель без развязки. Это только мои догадки, я не утверждаю, что это так и есть.
Хотелось бы услышать мнения людей в этом деле преуспевших. Заранее благодарю за советы.

А кто-нибудь пробовал использовать ВЧ модули от приёмников-передатчиков Турниги в режиме полудуплекса?

Может быть уже поздно

Лучше поздно, чем никогда. Пока тема не закрыта можно (и нужно, на мой взгляд) высказываться. Тем более, что Ваша информация весьма полезна.
А Вы каким образом раскопали как работает

Родная утилита от FrSky

? Анализатором подключались?

Осталось апробировать переделку на летающей модели, о чём отпишусь дополнительно. Ответить с цитированием Ответить с цитированием

Апробация состоялась. Отлётано два пака на 450-м вертолёте в воскресенье. Больше не смог - замёрз, пальцы вообще перестали слушаться. Впечатления сугубо положительные. Никакой разницы в управлении по сравнению со штатным резюком не заметил. Что пришлось сделать дополнительно - изменить D\R с 70 до 85 и проинвертировать канал крена\аэлеронов. Можно, конечно перевернуть датчик на 180гр, если дотошно соблюдать заводские настройки, но мне это показалось лишним.
Резюмирую: вариант рабочий, переделка удалась.

Не попробовав, не узнаешь…
P.S. Не удивлюсь если модеры скоро прикроют эту тему. Кроме нас с Вами никто не участвует в обсуждении.

В другой Вашей ветке rcopen.com/forum/f4/topic404604 в первом сообщении написано, что Вы уже делали перепрошивку на другом приемнике и все получилось. Если это так, то можно попробовать считать с того приемыша прошивку. Только считывать нужно в режиме стандартного STMовского бутлодера, для чего нужно убрать резюк 10кОм, притягивающий BOOT0 нога 44 на + питания, а вместо него припаять тумблер на проводочках. Далее: подключить FTDI-мост, замкнуть тумблер(коротнуть BOOT0 на землю) и подать питание на чип. После этого запустить Flash loader demonstrator настроить его как я уже писал выше и попытаться связаться с чипом. Должно получиться. Потом попробовать скачать с флэша прошивку в файл. Есть, правда, опасение, что китайцы попытались залочить флэш, но вроде бы во Flash loader demonstrator (как я понял) можно снимать любую защиту с флэша.

Попробуйте всё таки инициировать стандартный STMовский бутлодер воспользовавшись мануалом и припаяв проводки к нужным ногам.

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

Это как? Boot0(Pin) через резюк соединён с 3В, а Boot1(Pin) через резюк с землёй? Тогда, по логике вещей, ресет после загрузки программный, а когда включаешь питание камень сразу в режиме загрузки. Но в таком случае не понятно как же девайс работает в нормальном режиме?
А чо за проблема? припаяйте проводки и тумблер параллельно резистору от Boot0(Pin) к земле.

А был ли мальчик заводской бутлоадер? Может его потерли при прошивке и оставили только свой фрскаевский?

Чёт не очень в это верится. Китайцы лишний раз не почешутся, а тут свой бутлодер. Сомневаюсь я.

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

Не понял. В первый раз не трогали, а в какой раз трогали? И откуда вы знаете, что вообще производили действия с областью памяти бутлодера?

Никак. На расстоянии более 10-15 мм влияние магнита, даже расположенного строго вдоль оси ячейки Холла никак не отражается на выходном напряжении датчика.

Ну вот, наконец то это свершилось! Магнито-резюк установлен в передатчик на аэлероны. Для всех, кто захочет повторить - предупреждение: обязатнльно проверяйте полярность напряжения на проводах, идущих от резюков к плате контроллера! Красный провод может оказаться минусом, а чёрный плюсом! Китайцы - народ юморной. Я чуть не спалил датчик. Хорошо, что 5-ти вольтовый ВЕС на плате контроллера ушёл в защиту раньше, чем задымился датчик. Хотя чуть-чуть завоняло, но не фатально.
В среднем положении напряжение на выходе датчика, как и ожидалось - 2,5В. В крайних положениях напряжения немного отличаются - примерно на 0,3В. Однако, для меня этот момент не сильно принципиален, поскольку я практически никогда не пользуюсь 100% расходами. Если же необходимо, можно “подкрутить” ендпойнты.
Осталось апробировать переделку на летающей модели, о чём отпишусь дополнительно.

Пока не установил. Вчера вечером вошкался с фотками - они здоровенные получаются, надо было их ужать, подписать… Короче, сегодня может быть установлю свой магнито-резюк в передатчик. Планирую сперва канал аэлеронов переделать. Если попрёт, тогда все резюки разом заменю.

Похоже что все же заводской бутлоадер возможно попортить

Я сейчас глянул мануал по бутлодерам. Похоже, что всё таки там на заводе во флэш заливают, таки, прогу-бутлодер. Она расписана в Figure 6. Bootloader for STM32F10xxx with USART1. Так что мои утверждения по поводу аппаратного бутлодера были неверны. Вероятно не исключён вариант того, что Вы залезли в тот раздел памяти, где лежала прога-бутлодер и его повредили. К сожалению для Вашего камня в мануале не указывают где именно в памяти находится бутлодер.

Правильно ли я понял даташиты по установке выводов BOOT (писал в первом сообщении)?

Вроде бы правильно.

Никаких ресетов не надо дергать?

Ресет надо нажимать два раза: первый раз когда устанавливается режим бутлодера и второй раз когда программа залилась и перемычка с ноги Boot0(Pin) убирается, т.е. Boot0(Pin)=0 и Boot1(Pin)=0. Или оба раза передёрнуть питание.
Если не в лом, то можно попробовать написать свой бутлодер по блок схеме из мануала Figure 6., откомпилить его и залить через SWD ST-LINKом. Но это, конечно, на любителя.

Сейчас подумал ещё и возникла вот какая мысль: по уму(и по мануалу), та часть памяти, где лежит бутлодер залочена и стереть её можно только сняв защиту. В мануале описывается возможность раскурочивания бутлодера, но там описывается именно процедура снятия защиты с определённых секторов памяти. Каким образом Вы могли разлочить память под бутлодер - загадка…

залить прошивку не выйдет т.к. ее нет в нормальном виде (hex/bin).

А в каком она виде? Расширение не то? Посмотрите в блокноте - может это обычный hex-файл просто прилепили другое расширение.

приемник не распознается родной прогой т.к. переход в режим прошивки программный

Вот это я не понял. Это как происходит, если никаких команд в приёмник не поступает, поскольку он не видит компа.
Попробуйте в лоб: переименуйте расширение заливаемого файла на hex/bin и залейте в микроконтроллер по стандартному УАРТу.

Фотки, как обещал:

Я вчера часа два потратил на возню с фотиком, но он, собака, никак не заряжался. Лежал до этого год без дела, а когда понадобился - бастует. Сегодня на работе зарядил аккум от лабораторного источника - попробую помучить фотик снова. Если не получится сфотать, то нарисую эскизики.

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

Тогда я не понял что не так. Если приёмник “начал прошиваться”, то значит UART работает(работал). ОК. В данный момент исправность аппаратной части сохранена или Вы не проверяли?

производитель дабы подзаработать выпустил свой собственный конвертер USB-UART, а что бы его покупали инвертировал сигналы и в нем и в железках прошиваемых им.

Бутлодер в микроконтроллере от этого не перестал работать в том же режиме, как его выпустили с фабрики, поскольку он аппаратный. Инверсия сигналов в мосте продаваемом вместе с приёмником не отменяет заводских настроек UART микроконтроллера.

Хочу иметь загрузчик, с которым камень идет с завода для возможности программирования по UART.

Считайте, что он уже у Вас есть - лежит в микроконтроллере.

Я правильно понимаю что этот самый загрузчик мог слететь

Не слышал о таком никогда, но всё когда-нибудь случается в первый раз. Может Вы первый? Короче: маловероятно, что загрузчик слетел, поскольку он, скорее всего, аппаратный.

или он аппаратный и я просто что-то не так делал?

Во Вы и сами к этому пришли. Видно что-то не так. Проверьте по порядку: подтянуты ли RX и TX к плюсу через резюки, есть ли на них высокий уровень, проверьте установки порта, с которым Вы связываетесь. Должно быть: Рort Name-тот порт, который определяеься при подключении моста USB-UART; Baud Rate-115200; Parity-Even; Echo-Disabled. Ну и сам мост проверьте - определяется ли при подключению к компу, замкните RX и TX и плюньте что-нибудь из любой терминальной проги - если на приёме будет то, что передали - всё ОК. В общем, последовательно и не торопясь проверить всё железо. Удачи.

залил через STM32 ST-LINK Utility

Данная утилита предназначена для работы с программатором ST-LINK: www.st.com/web/en/catalog/tools/PF251168?s_searcht…
Для прошивки по UART используется программа STM32 and STM8 Flash loader demonstrator: www.st.com/web/en/catalog/tools/PF257525

Если я правильно понимаю процесс, то камень постоянно находится в режиме загрузки через UART и бутлодырь т.к. прозвонка показал: BOOT0 нога 44 через 10кОм висит на +5В. BOOT1 нога 20 через резистор висит на земле. т.е.

Не думаю. То, что ноги соединены так, это ещё не всё. В самой программе, которая заливается, может быть переход из режима загрузки в режим выполнения программы (RUN).

Для прошивки утилитой от FrSky необходимо коротить выходы 1 и 2 приемника, которые висят на 18 и 19 ногах STM, т.е. переход в режим программирования программный.

Я не могу знать, что удумали китайские программеры, но такой вариант не исключён.

хочу вернуть камень к “заводским настройкам”

Что есть “заводские настройки”? Для перепрошивки, частичного или полного стирания FLASH-памяти МК скачайте прогу Flash loader demonstrator, ссылку на которую я давал выше. Прочитайте мануал по этой проге, законнектитесь через UART и творите что хотите.

Приветствую всех.
Такая тема уже поднималась вот здесь: rcopen.com/forum/f4/topic175987/81, но т.к. вышеуказанная тема закрыта, я создал новую.
За последние пару месяцев у меня в моём пульте Турнига-9 вышли из строя два потенциометра на правом стике. Я их поменял на другие из старой Валкеровской аппы, но меня напрягает сам факт износа потенциометров и подлости, которые происходят непредсказуемо при нахождении модели в воздухе. Я пошуршал по форуму, нашёл вышеуказанную тему и решил попробовать. Результат мне не понравился совсем и я начал искать альтернативы. Конечно, самым “правильным” была бы установка AS5043 или даже AS5046 - 10(12)-битный контроллер с встроенным ЦАПом, который позволяет получить точность порядка 0,3гр. во всём диапазоне от 0 до 360гр. Однако, цена этого чуда совсем не гуманна: от 500руб у китаёзов и от 800руб в Москве. Я пока не готов к таким затратам, а посему остановился на датчике SS495A по 120руб. Но я не стал делать так как описывалось, т.е использовать линейное перемещение магнита относительно датчика(или наоборот). Я хотел иметь именно датчик поворота и желательно в корпусе старого потенциометра.
Магниты у меня остались со времён, когда я переделывал моторчики из CDROMa. Магниты размером 5х5х1мм.
Начал я с того, что попробовал одиночный магнит. Как я его ни крутил вокруг датчика - результат получался тухлый. Тогда я решил “удлиннить” магнит и склеил два магнита торцами. Получился магнит с размерами 10х5х1мм. Вот тут то дело пошло! Я разобрал старый потенциометр, доработал немного, оставив вращающуюся площадку на на оси, куда и приклеил магниты. Датчик расположен перпендикулярно магнитам, т.е ноги датчика торчат в направлении противоположном оси потенциометра. При ориентации магнита длинной стороной вдоль датчика на выходе 2,5В при питании от 5В. Здесь остановлюсь поподробнее. Конструкция примечательна тем, что датчик при изменении напряжения питания пропорционально изменяет напряжение на выходе, сохраняя равенство: Uвых=Uпит/2. При повороте магнита на угол от 0 до ±90гр напряжение на выходе меняется либо в плюс до Uпит либо в минус до GND. Линейность изменения напряжения сохраняется примерно в диапазоне ±75-80гр. Скорость изменения напряжения от угла поворота зависит от расстояния между магнитом и датчиком. У меня при зазоре 0-1мм напряжение меняется от от 0В до Uпит при угле отклонения ±45гр. Это фактически повторяет изменения напряжения на движке потенциометра при отклонениях стика от мин. до макс. Ну вот, вроде пока всё. Фотки выложу попозже.

Почитал ещё здесь …ardupilot.com/…/traditional-helicopter-configurat… и в части посвящённой настройкам ESC (Rotor Speed Control (RSC) using Output Channel 8 on APM2.5) нашёл кое-какие тонкости касающиеся как раз арминга.

• в меню “Rotor Speed Control” нужно выбрать Mode 1 или 2, не стоит выбирать в этом меню значение Disable, т.к. в этом случае не работает коллективный шаг.
• нужно установить в меню RSC Ramp Rate значение, которое будет определять время раскрутки ротора, если установить значение “ноль”, то ротор будет раскручиваться в соответствии с установками вашего ESC.
• есть не выделенная строчка, которая весьма важна: Also note the APM won’t arm in Mode 1 or 2 unless Ch8 is within 10 of RC8_Min. Имеется в виду, что Ваш АПМ не захочет армится в режимах Мод 1 или 2, если значение минимума 8-го канала не установлено в пределах 10.
  Так что советую обратить внимание на вышеперечисленные моменты(если, конечно, Вы ещё этого не сделали).

А плата всё таки какая?

Самое то интересное на прошивки квадра и самолеты, плайнеры всё работает а на верте нех…я

Я, конечно, не спец и на ардуинах не летаю, однако, если я правильно понимаю, прошивка то одна, а настройки разные. Смотрел я в ардуиновской среде разработки (Arduino IDE которая) и там по сути раскомментирывются те строки, которые определяют тип используемого шасси(frame). Т.е. когда раскомментируется HELI_FRAME, то программа начинает выдавать на выходы управляющие сигналы на органы управления вертолёта - по крену и тангажу на сервы свош-платы, а по руддеру на серву хвоста. На ESC же подаётся сигнал управления высотой. Это грубо, в первом приближении, так сказать. Думаю вы и без меня это понимаете, но хотел просто для терминологии разложить.
Так вот, если Вы утверждаете, что запрограммированная плата работает в конфигурации коптера и самолёта, то она должна работать и в вертолётной конфигурации. Вы, если не лень сделайте скриншоты тех мест программы, где Вы меняете настройки. Может статься, что это поможет делу и если не я, то кто-нибудь из спецов сможет сказать в чём ошибка.

Дима, так как там с непослушной системой дела? Или вы её забросили?
Кстати, хотел узнать какую платку вы мучили…

Усё! Допилил, наконец я конвертер! Вчера вечером уже подлётывал на 250-ке дома. Спасибо, мужики, большое за участие и помощь!

Для РРМ-сигнала 1024 - это 0%, 1536 - 50% и 2047 - 100%. Или в S.Bus 0 - это 0%, 1024 - это 50%, а 2047 - 100%? Или, иными словами, конвертировать надо так: (((Длительность_РРМ_импульса) - 1023) / 1023)*100% Так что ли?
Блин, если это так, то я чудак на букву “М”! Мне ж еще 7.03.2014 RW9UAO говорил о том же:

среднее положение столбика в фубаре - 1023, минимум - 0, максимум 2047. возможно вы неправильно конвертируете входящие данные.

А я прощёлкал клювом…

Провёл сейчас такой эксперимент: записал в 1-й канал значение 1024, во 2-й 1536 и в третий 2047. Таким образом, при подключении в 1-й канал, серва должна устанавливаться в “минимальное” положение; при подключении ко 2-му каналу - в “среднее” положение и при подключении к 3-му каналу в “максимальное” положение.
При подключении к FuBar, получилось следующее: серва в 1-м какале - положение “чуть меньше середины”; серва во 2-м канале - “середина”; серва в 3-м канале - “максимум”.
Выходит передаётся всё правильно, а интерпретирует FuBar как то странно. Или я неправильный вывод делаю?

Юрий, Вы всё ещё тут?! Приятно удивлён!
Файлик зипованый я посмотрел - он тот же, на который я давал ссылку.
Прцедуру я не вкурил. Зачем биты реверсировать? Это мне больше напоминает процедуру определения бита чётности. Короче, вот моя процедурка:

////************************************
////Конвертация. Длительность порядка 1760 мкСек(3538 инстр.циклов)
////************************************
void convertation()
{
int mask = 0x01; //Маска для проверки битов в Channel_Pulse[]
unsigned char buffer = 0; //Буфер для промежуточного хранения байта высчитанного из Channel_Pulse[]
char mask_buffer = 0b10000000; //Маска усановки битов в байтах buffer
char k = 0; //счетчик бит в байтах buffer
char n = 0; //счетчик байт в массиве DATA[n]

for(char p=0; p<8; p++) //Для каждого из 8-ми значений Channel_Pulse[]
{
for(char i=0; i<=10; i++) //Для 11 младших бит Channel_Pulse[p]
{
if(Channel_Pulse[p] & mask) //Если в i-ом разряде Channel_Pulse[p] единица
{buffer = buffer | mask_buffer;} //Пишем 1 в соответствующий разряд переменной buffer
else {buffer = buffer | 0x00;} //Иначе пишем 0
mask_buffer = mask_buffer >> 1; //сдвигаем 1 на разряд вправо в маске усановки битов в buffer
mask = mask << 1; //сдвигаем 1 на разряд влево в маске для проверки битов в Channel_Pulse[p]
k++; //добавляем +1 в счётчик бит в байтах buffer
if(k>=8) //Если счётчик бит в байтах buffer досчитал до 8
{
DATA[n] = buffer; //Пишем содержимое буфера в DATA[n]
mask_buffer = 0b10000000; //Устанавливаем 1 в 0-й разряд маски усановки битов в байтах buffer
k = 0; //Сбрасываем счётчик бит в байтах buffer
buffer = 0; //и очищаем буфер
n+=1; //добавляем +1 в счётчик байт в массиве DATA[n]
}
if(i>=10) //Если счётчик бит в байтах Channel_Pulse[p] досчитал до 10, то
{mask = 0x01;} //Устанавливаем 1 в 0-й разряд маски для проверки битов в Channel_Pulse[]
}
}
}

Она может и не очень красива(я программер тот ещё), но работает быстро и можно колбасить биты по всем направлениям меняя маску и направление сдвига. На выходе массив из байт для ЭсБуса.

О, Юрий, рад Вас снова видеть “в деле”.
Ваша идея понятна, только тогда каким образом дозаполнить оставшиеся пять бит в iPulseH ? Да и дальнейшая процедура заполнения байт S.Busa по Вашей схеме не ясна.
Я сейчас использую способ перераспределения бит посредством последовательного считывания из int iPulse начиная с младшего и потом установка считанного значения бита в очередном байте S.Busa тоже от младшего к старшему. Затем сдвиг iPulse и байта S.Bus. Заканчивается очередной байт, продолжаем в следующем.
Если интересно, могу процедуру сортировки выложить.
Фишка для меня была, в основном, в первом вопросе. Я перекопал много разных источников, но для себя 100% -го ответа не нашёл. Вот тут mbed.org/…/futaba-s-bus-controlled-by-mbed/ мужик проделал немалую работу, но мне это ясности всё равно не добавило.

Прошу разъяснить следующий момент: каким образом прочитать значение передаваемой длительности импульса в кадре S.Bus после старта?
Для примера возьмём самый простой вариант - первый канал. Итак, передача в S.Bus осуществляется методом MSb first (передаётся сначала самый старший бит). На передачу значения длительности первого канала отводится 8 бит(0-7) из первого переданного байта и 3 бита(0-2) из второго. Вопрос состоит в следующем: где среди этих 11 бит находится MSb? Я предполагаю, что он находится во 2-ом бите второго байта, т.е. 11-битное значение надо читать начиная со 2-го бита 2-го байта справа налево. Так ли это?
Второй момент, который я бы хотел понять: как рассовать биты из значения канала c типом unsigned int в два байта передаваемые через стандартный UART(в котором передача начинается с LSb), чтобы переданные байты образовывали число в формате протокола S.Bus?