S.Bus System
Не прошло и полгода, и я снова здесь. Всем доброго времени суток.
Неспешно и с большими перерывами ковыряясь со своим конвертером, я, таки, почти допилил его. Вот проверить, правда не на чем - девайс, под который я планировал конвертер, забыт на даче вместе с вертолётом, а других устройств понимающих S.Bus у меня нет. Посоветуйте какое-нибудь недорогое исполнительное устройство, которое можно купить в Москве, чтобы на практике проверить работу конвертера.
Вполне возможно, что обе скорости адекватно поддержать не сможете и один из уартов придется делать програмным.
Обе скорости нормально поддерживаются аппаратным уартом PIC16F1823,24,27 и т.п. при тактовой частоте в 8МГц. Это относительно новая серия “нановатт” Микрочиповских контроллеров, которые я купил поиграться по цене порядка 40 руб/шт. В них ещё до фига чего понапихано, весьма любопытная серия.
Однако, мне всё равно пришлось использовать ещё и программный уарт для приёма посылок с передатчика, поскольку я не смог заставить аппаратный уарт понимать 16-битные посылки без промежуточных стартовых и стоповых бит.
не смог заставить аппаратный уарт понимать 16-битные посылки без промежуточных стартовых и стоповых бит.
SPI
SPI
Не понял.
16-битные посылки без промежуточных стартовых и стоповых бит
можно вполне принимать с помощью контроллера SPI. не настраивается разве?
А где тактирование брать для SPI?
Дали мне mini V-Bar на пробу, подключил я свой декодер, настроил через прогу V-Staby на вход от S-Bus, подключил серву в канал руддера и… ничего. Не реагирует серва на передатчик. Хрен его знает где глядеть.
По картинке с цифрового анализатора всё отлично 25 импульсов: 0хF0 первый, потом 11 байт ненулевые(конвертированые из принятых с передатчика 8кан.х11бит), дальше 11 байт нулевые(поскольку нет больше каналов для конвертации) и в конце два байта 0х00. Сигнал инвертированный, старт-бит один, бит чётности, стопов два. Что не так - не пойму…
на вход SPI заводите свой сигнал. его же заводите на вход внешнего прерывания. произошло прерывание - запрещаем его, выплевываем 16 бит из SPI, скорость у вас такая-же как приходящий УАРТ. получили ваши 16 бит вез стартов-стопов. обработали, разрешили внешнее прерывание для следующей посылки.
баудрэйт С-БАС у вас сколько?
Я, вероятно, не настолько сведущ в микроконтроллерах, оттого не могу понять ход Вашей мысли. Если не трудно, разъясните попроще - для тупых.
на вход SPI заводите свой сигнал. его же заводите на вход внешнего прерывания.
Что такое свой сигнал? Откуда он берётся?
произошло прерывание - запрещаем его,
Чего запрещаем? Зачем использовать прерывание? Я вообще не люблю прерывания, если можно обойтись без них, то я их не использую.
выплевываем 16 бит из SPI
Куда “выплёвываем”?
скорость у вас такая-же как приходящий УАРТ
Скорость чего?
баудрэйт С-БАС у вас сколько?
100’000 бит/сек
Люди! Окажите посильное вспомоществование!
Подскажите насколько критична для исполнительных устройств частота следования кадров в протоколе S-Bus?
FU-BAR, а значит и большинству клонов V-BAR безразлично 7-11-14 мс фрэймы.
О! Сергей, спасибо за отклик!
Я немного другое имел в виду. У меня частота следования посылок(фреймов) 20 мСек. Может это влиять на результат обработки посылки исполнительным устройством?
Может это влиять на результат обработки посылки исполнительным устройством?
Не думаю, скорей всего отправляете “битый” кадр.
Всех приветствую. Преодолел ещё одну ступеньку на пути к S.Bus - сигнал с выхода моего конвертера воспринимается моим ФуБаром. Однако, не всё так хорошо, как хотелось бы. Сервы, подключенные в каналы ФуБара работают только в половине своего диапазона, т.е. от среднего положения рычаги отклоняются только в одну сторону. Может это как то связано с форматом данных? Я слышал у Футабы в передатчике настройка от -100% до +100% и середина это 0%, а у меня от 0% до 100% и середина - 50%. Я понимаю, что ширина сервоимпульса в крайних точка д.б. от 1000 до 2000 мкСек в обоих случаях, но может есть какие-то тонкости в передаче сигнала Футабы или S.Bus?
Петрович, ну вторая же ссылка в гугле…mbed.org/…/futaba-s-bus-controlled-by-mbed/
data 1-22 = [ch1, 11bit][ch2, 11bit] … [ch16, 11bit] (ch# = 0 bis 2047)
11 бит
з.ы. ради интереса померьте задержку, которую вносит ваш конвертер. и общее быстродействие. щелчок тумблера - срабатывание сервы. если будет больше 200 мс - то очень плохо.
ради интереса померьте задержку, которую вносит ваш конвертер. и общее быстродействие. щелчок тумблера - срабатывание сервы. если будет больше 200 мс - то очень плохо.
Сергей, Вы вероятно достаточно много знаете и вам, вероятно, кажется, что какие-то вещи не требуют разъяснения - они сами собой подразумеваются. Это не совсем так, уверяю Вас! Вот и в данном случае я не могу понять о каком тумблере вы говорите? Задержку конвертера я могу сказать и без тумблера, она составляет порядка 7-8 мСек. Я отслеживал этот момент на анализаторе: пришёл кадр с передатчика - начинаем отсчёт: проверка контрольной суммы, конвертация и стартовый байт посылки S.Bus - всё это занимает 7-8 мСек.
Петрович, ну вторая же ссылка в гугле…mbed.org/users/Digixx/noteboo...olled-by-mbed/ data 1-22 = [ch1, 11bit][ch2, 11bit] … [ch16, 11bit] (ch# = 0 bis 2047) 11 бит
При чём здесь 11 бит? Я именно 11 младших бит из каждого интового значения длительности канала расссовываю по байтам S.Bus. Каналы, кстати сказать, распределяются нормально и направление отклонения серв по элерону и элеватору правильное.
если ваш конвертер вносит задержку 7-8 мс - все нормально.
среднее положение столбика в фубаре - 1023, минимум - 0, максимум 2047. возможно вы неправильно конвертируете входящие данные. просто положите в элероны-элеватор-руддер значения 0, 1023 и 2047.
Ок, попробую передать фиксированные значения.
Сейчас посмотрел анализатором напрямую что выходит с Fu-Bara. На каналах 1,2,3 на тарелку перекоса идет сигнал от 1200 до 1800 мкСек с периодом в 7000 мкСек. На руддер идёт сигнал в полном диапазоне от 1000 до 2000 мкСек, но период меня поразил - всего 3000 мкСек! Может из-за того, что я в установках поставил цифровую машинку? Одако такого периода я никак не ожидал увидеть. На канале газа сигнал с периодом 17000 мкСек(17мСек) и его длительность не меняется, она примерно 1600 мкСек.
Выходит один только канал руддера отрабатывает весь диапвзон, а остальные хрен поймёшь чего.
Прошу разъяснить следующий момент: каким образом прочитать значение передаваемой длительности импульса в кадре 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?
-да, так
-ИМХО сдвигом и преобразованием типа, наподобии следующего
unsigned int iPulse ;
unsigned char iPulseL ;
unsigned char iPulseH ;
…
iPulseH = (char)(iPulse >>8);
iPulseL = (char)iPulse;
О, Юрий, рад Вас снова видеть “в деле”.
Ваша идея понятна, только тогда каким образом дозаполнить оставшиеся пять бит в iPulseH ? Да и дальнейшая процедура заполнения байт S.Busa по Вашей схеме не ясна.
Я сейчас использую способ перераспределения бит посредством последовательного считывания из int iPulse начиная с младшего и потом установка считанного значения бита в очередном байте S.Busa тоже от младшего к старшему. Затем сдвиг iPulse и байта S.Bus. Заканчивается очередной байт, продолжаем в следующем.
Если интересно, могу процедуру сортировки выложить.
Фишка для меня была, в основном, в первом вопросе. Я перекопал много разных источников, но для себя 100% -го ответа не нашёл. Вот тут mbed.org/…/futaba-s-bus-controlled-by-mbed/ мужик проделал немалую работу, но мне это ясности всё равно не добавило.
Я где то встречал процедуру считывания красивую, но ссылку никак не найду 😦 Комп слетал и где теперь та ссылка… Ну да ладно…
Следующий кусок просто получаете из следующего значения канала тем же сдвигом в требуемом направлении, ну куда надо биты передвинуть и преобразованием типа с последующим сложением уже имеющегося куска, например
iPulseL = TCNT1L;
iPulseH = TCNT1H;
iPulse = (((unsigned int)iPulseH)<<8) + iPulseL;
Вот еще полезная вещь, попалась тут на www.multirotorforums.com/showthread.php?9661-R7008…, чтоб не региться там файлик прилагаю
Перестановка битов в байте тут нарыл в инете:
char bit_reverse (char bits)
{
bits = ((bits & 0x0F) << 4) | ((bits & 0xF0) >> 4);
bits = ((bits & 0x33) << 2) | ((bits & 0xcc) >> 2);
bits = ((bits & 0x55) << 1) | ((bits & 0xaa) >> 1);
return bits;
}