roboforum.ru

Так, работать с ПИД нужно, когда все сервы "на проводе" ?
Почему именно полный байт надо для коэф, почему нельзя обойтись 0..200? (50..250)

ну, менять коэфф. на ходу конечно хорошо. Ставить лапку мягко, балансировать быстро, это я фантазирую

для коэф. полный байт не нужен, я про возвращаемые положения сервы. Мало 200 точек.
Ладно, главный не косяк - не 9 бит, сейчас надо быстро окучить электронику туррели, сделал конвертилку джойстика PS2 в rs232 9600, ща прикручу к серве rs232 и буду пробовать.
А тут еще STM32VLDISCOVERY ко мне идут, покурил их вчера - чума, какие наф пики

Если 200 точек мало, то и 250 будет мало - передавай два раза по 0..100

будет тебе 10 000 положений

Добавлено спустя 1 минуту 5 секунд:
Re: Переделка сервы HXT12K (T-Pro MG945) под постоянное вращение
Кстати, да, сделай, чтобы первые 50..250 были грубым положением, а если потом снова пришло 50..250 - не для следующей сервы ставим, а этой же уточняем положение

ALS писал(а):Как вариант - можно сделать "двойной" протокол:
9 бит для работы с труЪ-железом
и 8 бит + удержание DTR - для подключения к ПК.
Добавится еще один пин для управления, но он будет использоваться только при работе

говорю же, надо минимальный напильнинг стандартной сервы, т.е. штатный сигнал управления сервой ppm перевести в 1-проводной rs232...

Добавлено спустя 3 минуты 26 секунд:

=DeaD= писал(а):Если 200 точек мало, то и 250 будет мало - передавай два раза по 0..100 будет тебе 10 000 положений

да, согласен, но надо уйти от фрагментации данных, 2 байта положения с 300 точками проще передать...

я это понял.
и в этом вам могут (гипотетически) помочь 9 бит.
но тогда возникает вопрос с подключением к ПК.
поэтому я и предложил второй вариант (см. там же). кому нужно будет подключение этих серв именно к ПК - аппаратный транслятор в помощь (своего рода прокладка между ПК и сервой).

Dmitry__ писал(а):да, согласен, но надо уйти от фрагментации данных, 2 байта положения с 300 точками проще передать...

Уйти от фрагментации - это как? байты всё равно фрагментируют данные. Про 2 байта положения с 300 точками вообще не вкурил...

ну, как ацп 12 бит в контроллерах, левое или правое выравнивание 12 бит в 2-х байтах.

Разве +\- операция по добавлению-вычитанию 50 решает?

я так понял у тебя протокол расчитан на очень короткие сообщения? 2-3 байта кадр?

Добавлено спустя 3 минуты 43 секунды:
Re: Переделка сервы HXT12K (T-Pro MG945) под постоянное вращение
т.е. crc там места нет? очень удобно для синхр. кадров...

а плотность информации увеличится, если взять не 8 бит, а 4, 5, 6 или 7?

Dmitry__ писал(а):я так понял у тебя протокол расчитан на очень короткие сообщения? 2-3 байта кадр?

Да в целом пофиг изначально, хоть 20 байт подряд чтобы пачку серв выставить.

Dmitry__ писал(а):т.е. crc там места нет? очень удобно для синхр. кадров...

Расширить протокол конечно можно, но ты же сам говоришь, что всего 400 байт осталось в памяти контроллера?

Angel71 писал(а):а плотность информации увеличится, если взять не 8 бит, а 4, 5, 6 или 7?

Думал, как вариант, 7-бит режим и бит адреса (аналог 9-битного адресуемого уарт), что увеличит плотность информ., но есть соблазн в 7-ми битном режиме перейти на передачу ASCII кодировкой, что уменьшит плотность.

=DeaD= писал(а):Расширить протокол конечно можно, но ты же сам говоришь, что всего 400 байт осталось в памяти контроллера?

Подсчет crc займет 20 байт памяти, что намного меньше чем алгоритм поиска начала кадра при потере синхр. в режиме постоянного потока данных между контроллером и сервами.
И с crc дрыгов серв не будет при помехах...

Dmitry__ писал(а):Подсчет crc займет 20 байт памяти, что намного меньше чем алгоритм поиска начала кадра при потере синхр. в режиме постоянного потока данных между контроллером и сервами

Ну дык вместо байта CRC делайте паузы

сами создали проблему, сами решаем

пока редактировал сообщение, ты ответил

>И с crc дрыгов серв не будет при помехах...

Добавлено спустя 3 минуты 10 секунд:
Re: Переделка сервы HXT12K (T-Pro MG945) под постоянное вращение
ладно, делаю "тупо в лоб", чтоб быстро запустить туррель, там и канал однонаправленный и ресурсы такие не нужны...
А с будущим протоколом - курю бамбук...

Вот именно, а то каждый раз как кто-то начинает протокол проектировать для термодатчика - получается очередной TCP/IP.