S.Bus System

RW9UAO
MPetrovich:

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

SPI

RW9UAO

16-битные посылки без промежуточных стартовых и стоповых бит

можно вполне принимать с помощью контроллера SPI. не настраивается разве?

MPetrovich

А где тактирование брать для SPI?
Дали мне mini V-Bar на пробу, подключил я свой декодер, настроил через прогу V-Staby на вход от S-Bus, подключил серву в канал руддера и… ничего. Не реагирует серва на передатчик. Хрен его знает где глядеть.
По картинке с цифрового анализатора всё отлично 25 импульсов: 0хF0 первый, потом 11 байт ненулевые(конвертированые из принятых с передатчика 8кан.х11бит), дальше 11 байт нулевые(поскольку нет больше каналов для конвертации) и в конце два байта 0х00. Сигнал инвертированный, старт-бит один, бит чётности, стопов два. Что не так - не пойму…

RW9UAO

на вход SPI заводите свой сигнал. его же заводите на вход внешнего прерывания. произошло прерывание - запрещаем его, выплевываем 16 бит из SPI, скорость у вас такая-же как приходящий УАРТ. получили ваши 16 бит вез стартов-стопов. обработали, разрешили внешнее прерывание для следующей посылки.
баудрэйт С-БАС у вас сколько?

MPetrovich

Я, вероятно, не настолько сведущ в микроконтроллерах, оттого не могу понять ход Вашей мысли. Если не трудно, разъясните попроще - для тупых.

RW9UAO:

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

Что такое свой сигнал? Откуда он берётся?

RW9UAO:

произошло прерывание - запрещаем его,

Чего запрещаем? Зачем использовать прерывание? Я вообще не люблю прерывания, если можно обойтись без них, то я их не использую.

RW9UAO:

выплевываем 16 бит из SPI

Куда “выплёвываем”?

RW9UAO:

скорость у вас такая-же как приходящий УАРТ

Скорость чего?

RW9UAO:

баудрэйт С-БАС у вас сколько?

100’000 бит/сек

MPetrovich

Люди! Окажите посильное вспомоществование!
Подскажите насколько критична для исполнительных устройств частота следования кадров в протоколе S-Bus?

RW9UAO

FU-BAR, а значит и большинству клонов V-BAR безразлично 7-11-14 мс фрэймы.

MPetrovich

О! Сергей, спасибо за отклик!
Я немного другое имел в виду. У меня частота следования посылок(фреймов) 20 мСек. Может это влиять на результат обработки посылки исполнительным устройством?

rual
MPetrovich:

Может это влиять на результат обработки посылки исполнительным устройством?

Не думаю, скорей всего отправляете “битый” кадр.

7 days later
MPetrovich

Всех приветствую. Преодолел ещё одну ступеньку на пути к S.Bus - сигнал с выхода моего конвертера воспринимается моим ФуБаром. Однако, не всё так хорошо, как хотелось бы. Сервы, подключенные в каналы ФуБара работают только в половине своего диапазона, т.е. от среднего положения рычаги отклоняются только в одну сторону. Может это как то связано с форматом данных? Я слышал у Футабы в передатчике настройка от -100% до +100% и середина это 0%, а у меня от 0% до 100% и середина - 50%. Я понимаю, что ширина сервоимпульса в крайних точка д.б. от 1000 до 2000 мкСек в обоих случаях, но может есть какие-то тонкости в передаче сигнала Футабы или S.Bus?

RW9UAO

Петрович, ну вторая же ссылка в гугле…mbed.org/…/futaba-s-bus-controlled-by-mbed/

data 1-22 = [ch1, 11bit][ch2, 11bit] … [ch16, 11bit] (ch# = 0 bis 2047)

11 бит

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

MPetrovich
RW9UAO:

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

Сергей, Вы вероятно достаточно много знаете и вам, вероятно, кажется, что какие-то вещи не требуют разъяснения - они сами собой подразумеваются. Это не совсем так, уверяю Вас! Вот и в данном случае я не могу понять о каком тумблере вы говорите? Задержку конвертера я могу сказать и без тумблера, она составляет порядка 7-8 мСек. Я отслеживал этот момент на анализаторе: пришёл кадр с передатчика - начинаем отсчёт: проверка контрольной суммы, конвертация и стартовый байт посылки S.Bus - всё это занимает 7-8 мСек.

RW9UAO:

Петрович, ну вторая же ссылка в гугле…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. Каналы, кстати сказать, распределяются нормально и направление отклонения серв по элерону и элеватору правильное.

RW9UAO

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

MPetrovich

Сейчас посмотрел анализатором напрямую что выходит с Fu-Bara. На каналах 1,2,3 на тарелку перекоса идет сигнал от 1200 до 1800 мкСек с периодом в 7000 мкСек. На руддер идёт сигнал в полном диапазоне от 1000 до 2000 мкСек, но период меня поразил - всего 3000 мкСек! Может из-за того, что я в установках поставил цифровую машинку? Одако такого периода я никак не ожидал увидеть. На канале газа сигнал с периодом 17000 мкСек(17мСек) и его длительность не меняется, она примерно 1600 мкСек.
Выходит один только канал руддера отрабатывает весь диапвзон, а остальные хрен поймёшь чего.

MPetrovich

Прошу разъяснить следующий момент: каким образом прочитать значение передаваемой длительности импульса в кадре 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?

PigTail

-да, так
-ИМХО сдвигом и преобразованием типа, наподобии следующего

unsigned int iPulse ;
unsigned char iPulseL ;
unsigned char iPulseH ;

iPulseH = (char)(iPulse >>8);
iPulseL = (char)iPulse;

MPetrovich

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

PigTail

Я где то встречал процедуру считывания красивую, но ссылку никак не найду 😦 Комп слетал и где теперь та ссылка… Ну да ладно…
Следующий кусок просто получаете из следующего значения канала тем же сдвигом в требуемом направлении, ну куда надо биты передвинуть и преобразованием типа с последующим сложением уже имеющегося куска, например
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;
}

sbus.zip

MPetrovich

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

////************************************
////Конвертация. Длительность порядка 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[]
}
}
}

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