VCoder2 - Новая версия ПО для Turnigy/Eurgle/FlySky 9x

Новая прошивка будет на русском языке.

Поскольку аппаратура может быть использована с различными ВЧ модулями в функционал закладываю возможность задания 3-5 модулей ВЧ используемых в моделях, например, ВЧ Турнига, ВЧ Спектрум (инверсный сигнал), ВЧ Eurgle\HK (диапазоны каналов от 800 до 2200 мкс) и т.д.

Для каждой модели можно будет указать настройки какого ВЧ модуля необходимо использовать - это соответственно длительности каналов, количество каналов, полярность сигнала ppm

Для включения\выключения микшеров будут использованы свободно назначаемые условия, например,
логические условия:
(GEAR & TRUE) - выключатель GEAR включен
(!THR.CUT & TRUE) - выключатель THR.CUT выключен
(GEAR & THR.CUT) - выключатели GEAR и THR.CUT включены
математические условия
(THROTTLE > 30%) - ручка тяги в позиции более 30%
(THROTTLE < 10%) - ручка тяги в позиции менее 10 %

Таким образом микшеры можно будет включать по любому состоянию органов управления - из этого всего делаю вывод что полетные режимы как независимые наборы данных - просто не нужны… можно сделать 3,4,5,6… условий каждое из которых при установке в истину будет означать включение того или иного полетного режима (набора микшеров)

Дополнительно в микшеры вводим кривые и точки каналов - таким образом наложение кривых будет осуществляться на этапе микширования (в первой версии наложение кривых было после работы всех микшеров)
В микшеры дополнительно будут введены точки каналов (левая, центр, правая)

Вопрос возникает нужно ли у самого канала дополнительно иметь кривую ?
или кривых при микшировании будет достаточно ?

В принципе можно сделать кривые и в микшерах и в канале (сначала обработаются первые, после всех микшеров вторые)

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

Это будут простые логические операции И, ИЛИ, НЕ, - с логическими значениями операнда
Арифметические операции +, -, /, %, * - с процентными значениями операнда

В принципе можно попробовать сделать вторую версию кодера открытым проектом - если конечно найдутся те кто пожелает участвовать в разразботке

Кстати, планирую немного по другому организовать обработку каналов в прошивке - не как это было сделано у Фокуса (внутри прерывания) - так как длительные вычисления в прерывании делают невозможным захват внешнего ppm сигнала с тренерского разъема… Да и отрисовка одного и того же экрана впустую в цикле тоже смысла большого не имеет…

В настоящее время планирую использовать 3 таймера

Timer0, прерывания с частотой около 100 Гц - это будет системный счетчик используемый для организации равных интервалов действий прошивки, пока хочу опробовать в прерывании счетчик и в основном цикле программы обрабатывать вызовы в зависимости от его значения

switch (Timer0Counter) {
case 0: { опрос аналоговых каналов
}
case 1: { опрос клавиатуры
опрос триммеров
}

case 5: { Timer0Counter=0;
}
}
Это необходимо поскольку в зависимости от сложности модели частота исполнения цикла может меняться (в тестах у меня доходило до 120 циклов в секунду) и следовательно “поплывут” интервалы опроса клавиатуры, опроса аналоговых каналов и т.д.

Далее будет обработка условий, микшеров, фильтров,

далее, работа с экраном…

Независимо от этого цикла будет генерироваться сигнал ppm на вывод и на захват… - это позволит избежать недавно исправленной ошибки с обработкой ppm в первой версии прошивки где из за большого объема вычислений в паузе между импульсами ppm мы получали сдвиг значения первого канала на выходе передатчика… в предлагаемом решении мы можем получить полную обработку каналов не с частотой 50 гц а например с частотой 40 гц… или 30 гц… - причем поскольку идет дискретная обработка каналов а не инкрементная - на выходе изменений мы не заметим так как быстродействие серв все равно намного меньше…

Timer1 - генерация сигнала ppm, - минимальный размер кода исполняемого в прерывании

Timer3 - захват сигнала ppm, минимальный размер кода исполняемого в прерывании

Для включения\выключения микшеров будут использованы свободно назначаемые условия…
(GEAR & THR.CUT)

в примере показаны пара условий, а сколько планируется использовать выражений в условии? вот такое прокатит: (AIL_DR & !ELE_DR | !RUD_DR)?

(!THR.CUT & TRUE) - выключатель THR.CUT выключен

несколько необычно. почему, например, не (THR.CUT & FALSE)

Вопрос возникает нужно ли у самого канала дополнительно иметь кривую ?
или кривых при микшировании будет достаточно ?

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

в примере показаны пара условий, а сколько планируется использовать выражений в условии? вот такое прокатит: (AIL_DR & !ELE_DR | !RUD_DR)?

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

условие_1:
!ELE_DR

условие_2:
AIL_DR & условие_1

условие_3:
!RUD_DR

условие 4:
Условие_2 | условие_3

результат в условии_4

Всего условий планируется 32 (нужно больше ?)

несколько необычно. почему, например, не (THR.CUT & FALSE)

при операции И: (False И False) дает False
гм… получается что описанное выше условие проще сделать так: (!THR.CUT)

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

гм… кривая разве накладывается на орган управления ?!
может лучше сделать кривую при микшировании и\или после всех вычислений на полученное значение канала (после наложения всех микшеров) этого будет достаточно ? (особенно интересует достаточность функционала для вертолетов, для самолетов таких извратов не нужно и достаточно кривую наложить на канал после всех микшеров)

у меня описание условий пока в голове следующее:
побайтно
00 - вид условия
01 - операнд условия 1
02 - операнд условия 2

вид условия:
00 - нет операции, условие всегда ИСТИНА
логические операции
01 - лог. И
02 - лог. ИЛИ
03 - лог. НЕ
арифметическое сравнение
10 - операнд1 > операнд2
11 - операнд1 < операнд2
12 - операнд1 = операнд2
13 - операнд1 != операнд2
дополнительные арифметические операции
20 - операнд1 > |операнд2| - больше по модулю
21 - операнд1 < |операнд2| - меньше по модулю
арифметические выражения
30 - операнд1 + операнд2
31 - операнд1 - операнд2
32 - |операнд1|
33 - операнд1 \ операнд2
34 - операнд1 % операнд2
35 - операнд1 * операнд2

байт описатель операнда
битовое поле
7 6 5 4 3 2 1 0
| | | ++++++ - номер значения типа
| | |
++±—: вид операнда
0 - нет значения (пустое значение)
1 - значение переменной
2 - значение органа управления (UCH - в первой версии)
3 - значение логического канала (LCH)
4 - значение функции
5 - значение условия\выражения
6 - не определено
7 - не определено

младшие 5 бит - определяют сколько вариантов каждого операнда может быть - 32.
соответственно у нас 32 переменных, 32 условия\выражения, 16 логических каналов, 32 функции

Если кто где видит не соответствие или есть какие-то пожелания по возможным операциям или функционалу- пишите

Переменные

в первой версии как то не хватает фиксированных значений некоторых переменных чтобы задав значения параметра в одном месте - значение изменилось в нескольких местах (например микшерах)…
частично это решалось заданием значения для какого либо канала UCH и использование этого канала в качестве коэффициента микширования в регулируемых микшерах…
во второй версии прошивки планируется использовать переменные более широко, например, при использовании встроенных наборов микшеров для летающего крыла, или автоматов перекоса вертолетов и т.д. - параметры которые отвечают за те или иные варианты настроек будут вынесены в переменные, и мы таким образом получим возможность менять коэффициенты микширования для фиксированных микшеров (это один из способов применения), или например фиксированные значения можно будет применять в условиях…

значения переменных можно будет изменять и при помощи Органов управления (UCH)
как было написано выше всего возможно 32 переменных

переменные это значение от -120% до +120% (241 значение), либо 0, 1 для логических операций(2 значения)

формат следующий
00 - вид переменной
01 - значение переменной

вид переменной
00 - переменная не задана
01 - фиксированное значение заданное в поле 01
02 - значение органа управления, номер органа управления в поле 01
03 - значение условия\выражения, номер условия\выражения в поле 01

Микшеры

вот что нужно обязательно обсудить так это микшеры !

00 - условие для работы микшера (только при истинности условия)
01 - номер логического канала получателя в битах 3210, вид коэффициента микширования бит 4 (0 - фиксированный, 1 регулируемый)
02 - номер канала источника в формате байта описателя операнда (описано в условиях)
03 - используемая микшером кривая

а вот теперь самые спорные и требующие обсуждения параметры
04 - точки канала получателя (левая, центр, правая)
05 - точки канала источника (левая, центр, правая)

7 - коэффициент микширования, в случае регулируемого коэффициента микширования - в формате байта описателя условия

нужно ли в микшере указывать точки каналов ?
в принципе можно изменение точек каналов по условию сделать и в самих каналах…
с другой стороны параметры левой и правой точки вряд ли подлежат изменению (физические ограничения каналов), а вот центр возможно и нужно изменять… - так может просто задавать центральную точку ?

Органы управления

Думаю что никаких изменений относительно первой версии не потребуется…
В принципе можно сделать возможность задания центра для аналоговых каналов - нужно кому ? с другой стороны центры задаются при калибровке…

У каждого органа управления будет 2 параметра - значения минимума и максимума, для дискретных каналов генерируемое значение либо мин. либо макс. для аналоговых генерируемое значение может изменяться плавно от мин. до макс. (в общем как и в первой версии)

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

сколько всего много, соберусь с мыслями и отпишусь попозже. однако про “может лучше сделать кривую при микшировании и\или после всех вычислений на полученное значение канала” скажу отдельно.

кривая - по сути переменный коэффициент. смотрим (микшер со сдвигом):
(нач. знач. канала + микшер) * коэфф.
(нач. знач. канала * коэфф.) + микшер

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

можно тогда ввести параметр на то когда применять кривую…
0 - кривая применяется на значение органа управления
1 - кривая применяется на результат микширования
2 - кривая применяется к результирующему значению канала…

так пойдет ?

куда прицепить управление средней (нулевой) точкой канала ?

есть идея для каждого канала хранить несколько (3,5 ?) точек в формате
00 - номер условия (если истина - точка активна)
01 - значение нулевой точки…

или лучше эти точки задавать в микшере ?
или опять таки сделать оба варианта ?

недостаток двойных вариантов - расход памяти моделью… соответственно будут заморочки с архивацией модели перед ее сохранением на V-Disk

Виталь, наверно нужно таки сделать возможность при субтриммировании устанавливать и среднюю точку канала и крайние и это все на одной вкладке. может ошибаюсь на в предыдущей версии прошивки это было бы здорово… а то там на одном экране - средние точки а на другом крайние. и этта… думается что задание крайних и средних точек должно быть независимым… то бишь сдвинул среднюю - а крайние остались так же. ну и по микшерам: неплохо бы добавить “готовые” микшеры типа - 2 машинки на РВ, 4 машинки на крыло - типа 2 элероны-2 флапы(щитки) и микшер типа элероны с РВ в противофазе (для уменьшения радиуса петли)

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

а на счет крайних и средних точек - в первой версии эти точки абсолютно независимы !! среднюю или любую из крайних можно двигать без изменения остальных точек… раньше была проблема ухода точек если канал инвертировался… но эта ошибка исправлена уже очень давно… точки в первой версии не уходят… и не будут уходить во второй…

готовые микшеры будут ! главное не пропадайте когда я буду спрашивать какие нужны… сейчас у меня есть набор желаемых микшеров для вертов (от Дмитрия HikeR), по самолетам соответственно летающее крыло, 2 сервы на элероны (флапероны)…
в принципе главное движок написать для предустановленных микшеров, а потом накидаю сколько захотите…

не. не пропаду… а нсчет независимости при движухе точек… хмм… я тут начал среднюю точку двигать на 6 канале - и крайние поползли…

такого не может быть Андрей,

какую версию используешь ?

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

уточни - если я ошибаюсь - то нужно исправлять !!! скинь мне на мыло еепром !

так… вкладка LCH MIDDLE ползут. при изменении среднего значения… прошивка не самая последняя , может поэтому??? ща солью епром и закачаю самую последнюю

самую последнюю версию закатал… тож самое… 😢
епром отправил через квип - включишь аську - получишь ссылку . куда то твой емейл у мну затерялсо…

я тут комп поменял… аську не помню…

кинь на gorbukov@yandex.ru

ураа!! я квип нашел нормальный!!

мой номер в аське 600-989-219

дико звиняюся - невольно дезинформировал народ - усе пашет нормально - эт я натупил
Эти цифры показывают расстояние центральной точки от крайних . нужно для настройки дифференциала . а я то дурак подумал что это именно ползут точки

Виталий, я думаю полетные режимы всеже надо оставить - например для 3д и пилотажного режима так гораздо удобнее переключаться чем
по условиям.

Еще по таймеру - посмотрел свой старый мультиплекс там таймер считает от нуля и до установленного потом аларм, и таймер продолжает считать т.е. видно сколько перелетываешь. Хорошо бы это реализовать.

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

То что собираетесь реализовать логические условия - это очень хорошо.

Желаю творческих успехов. Как вернусь с отпуска буду готов тестировать.

так фактически режимы и остануться…
только это будут
условие_1 - для первого режима
условие_2 - для второго режима
и так далее… в принципе количество режимов ограничено только количеством условий…

любой микшер и любые точки каналов, любые кривые, функции будут включаться в зависимости от условий…

просто хочу уйти от фиксированного количества режимов - для самолетов нужно 2 иногда 3 режима, для вертов минимум 3… для планеров вообще и 3 и 4 и 5… то есть сколько фиксированных не делай - всегда будет мало…
лучше сделать вручную создаваемые - каждый для себя сделает сам сколько захочет! плюс сам назначит каким способом эти режимы будут включаться (один из способов включения режима HikeR уже показал: AIL_DR = ON
ELE_DR = OFF
RUD_DR = OFF
​ это условие может быть использовано как режим для включения цепочки микшеров, кривых, точек, и т.д.
причем
AIL_DR =ON
ELE_DR = ON
RUD_DR = OFF
​ может быть по выбору либо другим режимом либо просто комбинацией отключающий предыдущий режим…

вопросы остались по кривым в микшерах и по точкам каналов…

никто не хочет высказаться - где эти параметры лучше использовать - при микшировании или при последующей обработке каналов ?

просто хочется написать прошивку пригодную для использования с вертолетами и планерами - но чую что опять не найду тех кто летает на них и прошивка опять получится чисто самолетная…
а для самолетной прошивки как раз все эти навороты в виде кривых в микшере или точек каналов ИМХО не нужны…

пишу новый движок меню, так как старый не устраивает по скорости работы… да и прошивка сейчас по другому строиться - не получиться по старому обрабатывать…

вопрос - как лучше сделать реакцию на нажатие кнопок меню?
есть два варианта:

1. как было в первой версии прошивки - при удержании кнопки более какого то времени генерируется нажатие, потом через еще какое то время генерируется повтор…
2. вариант стандартной прошивки - при удержании кнопки в течении какого то времени и потом ее отпускании - генерируется нажатие. повтора как такового при навигации по меню нет…

в первом случае иногда удобно нажать кнопку и держать ее пока в нужный пункт меню не попадешь…
но иногда мне был бы удобен второй вариант - нажал, отпустил - переместился на 1 пункт… никогда не проскочишь нужный…

а как удобно вам ?

если чисто навигация по меню - то лучше второй вариант наверное. но желательно меню типа закольцевать по возможности

да кольцо уже сделал 😃

еще есть какие мнения…?

Виталий тут еще какое дело, при сохранении файла, на старой прошивке, если при этом включен приемник модели - то на время сохранения сервы загоняят в крайние позиции и что неприятно канал газа тоже. Был у меня несанкционированный взлет когда менял параметры на модели.

2. вариант стандартной прошивки - при удержании кнопки в течении какого то времени и потом ее отпускании - генерируется нажатие. повтора как такового при навигации по меню нет…

по меню ходить одиночными нажатиями вполне допустимо, однако если придется вдруг где-то поменять значение -50 на +50 путем сотни нажатий — то вас проклянут 😉

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

а для самолетной прошивки как раз все эти навороты в виде кривых в микшере или точек каналов ИМХО не нужны…

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

Виталий тут еще какое дело, при сохранении файла, на старой прошивке, если при этом включен приемник модели - то на время сохранения сервы загоняят в крайние позиции и что неприятно канал газа тоже. Был у меня несанкционированный взлет когда менял параметры на модели.

В другую ветку !
здесь вторая версия !

по меню ходить одиночными нажатиями вполне допустимо, однако если придется вдруг где-то поменять значение -50 на +50 путем сотни нажатий — то вас проклянут 😉

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

ну это я понимаю… процедуру перепишу чтобы регистрировала оба типа нажатия… для меню будет браться pushUp, а для изменения значений наверное pushHold…
скорость автоповтора для puchHold будет регулироваться…
да в принципе и для pushUp тоже можно сделать регулируемую задержку от дребезга

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

блин… дорого это для органа управления применять кривую 😦( эхх… хотя согласен что это наверное самый правильные способ…
так и буду делать !

значит вопрос с кривыми решен - кривая всегда будет накладываться на входящее значение в микшер !!

вопрос что делать с точками каналов - нужны они в микшере или достаточно будет в настройках каналов ?

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

все. сделал переписал обработчик чтобы он мог работать регистрируя и нажатия pushUp и нажатия pushHold

unsigned char rkey; // хранимый код нажатой кнопки
unsigned char presstime; // время нажатия кнопок для регистрации нажатия
unsigned char pushUpKey; // код нажатой и отпущенной кнопки
unsigned char pushUpReady; // признак уже считанного кода pushUp

// новая процедура опроса кнопок меню
void readMenuKeysNew() {
unsigned char temptime;
unsigned char tempkey;

tempkey=PINB &0xFE;

if (tempkey!=254) { // нажата одна из кнопок меню
if (tempkey!=rkey) { // регистрируем нажатие кнопки меню
rkey=tempkey; // запоминаем какая клавиша нажата
presstime=counter100; // запомним значение 100герцового счетчика
}
else { // кнопка меню удерживается
if (presstime<counter100) { // пересчитываем время если произошел переход счетчика через ноль
temptime=255-presstime+counter100;
} else temptime=counter100-presstime;
//в temptime время удержания кнопки

// определяем достаточное ли время удерживается кнопка меню в режиме PushUp
if ( (pushUpReady==0) && (temptime>E_key_PushUp_press_time) ) {
pushUpKey=tempkey & 0xFE;
pushUpReady=1;
}
// определяем достаточное ли время удерживается кнопка меню в режиме pushHold
if (temptime>E_key_PushHold_press_time) {
readyMenuKey=rkey; // регистрируем нажатие кнопки меню
rkey=254;
}
}
}
else {
rkey=254;
if (pushUpReady==1) pushUpReady=2;
}
}

// процедура получения кода кнопок меню PushUp
unsigned char getPushUpMenuKeysCode(void) {
unsigned char t;
if (pushUpReady==2) {
pushUpReady=0;
t=pushUpKey;
} else t=254;
return t;
}

// процедура получения кода кнопок меню PushHold для обработки
unsigned char getPushHoldMenuKeysCode(void) {
unsigned char t;

t=readyMenuKey & 0xFE; // сохраняем код перед сбросом

if (t!=254) {
readyMenuKey=254; // сбрасываем код нажатых клавиш
}
return t; // возвращаем код клавиш
}

в программе необходимо циклически вызывать readMenuKeysNew()
а в местах где нужно получить код нажатой кнопки:

• для pushUp - getPushUpMenuKeysCode;
• для pushHold - getPushHoldMenuKeysCode();

выходные коды функций соответственно одинаковые… 254 - нет нажатия…

значит вопрос с кривыми решен - кривая всегда будет накладываться на входящее значение в микшер !!

эээ… у вертов обычная схема - 3-й канал микшируется минимум на два других, собственно газ и общий шаг винта. кривые (или скорее набор точек) у них разные и привязаны к полетным режимам.

предложенная схема учитывает этот момент? то есть не пойдет ли в разные микшеры одна и та же кривая (набор точек)?

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

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

все настройки будут построены по схеме реляционной БД…
отдельно массив кривых, с индивидуальными номерами - которые указываются в микшерах… таким образом разные микшеры смогут использовать одни и те же кривые (в первой версии прошивки кривые были привязаны к каналу и полетному режиму)
либо наоборот разные микшеры разные кривые - даже если источник значения будет один (например в нашем случае thro)

так пойдет ?

точно так же будет массив точек каналов…

там смещение средней точки нужно делать или нет ?

Виталь, ответь на 2 вопроса. Это (В2) будет “Наш ответ китаю?” или для себя любимого… ? Просто, в первом случае - давно пора на рцгрупс (ну или хотябы в отдельную ветку тут) и, если уж хочется русский - то как опцию (в меню, усл. компиляцию - не важно). А если “для себя”, то вполне возможно не стоит много писать, а стоит много летать. Взгляды и предпочтения со временем меняются. Хочется чего-то нового и принципиально другого. А вот чужие стериотипы - могут сбить с толку. Я вот, к примеру, задумался, как из Р/У планера сделать частично свободнолетающий. 😃 Т.е. - нажал кнопку - планер отработал определенную последователность комманд, как свободники по таймеру. Догадаешься для чего?
А с подходом - “реализовать все и вся” - много противоречивых моментов выползает. Учитывать все пожелания? - там народ танками управлять собирается, и целой флотилией сразу… 😃 Тогда уж лучше интерпритатор (бейсика? Английского? Русского?) написать, чтоб любой страждущий прошивке свои пожелания скармливал и она делала все “пучком”. Кстати, а RC-OS не на этом принципе работает? 😃

Я все прошивки пишу для “себя любимого” 😃 Ответ Китаю - просто для красоты слова 😃
Просто у меня сейчас есть пожелания по функционалу прошивки которые пока никак не реализованы…

первая версия - это был пробный шар… если так можно сказать - способ получить уверенность что все что думаю реализуемо и достижимо… очень многое в первой прошивке было скопировано (идея генерации сигнала ппм, например), чтото подсмотрено у других… чтото придумано…

Сейчас я готов написать прошивку на которой возможно и остановлюсь (по крайней мере скорее всего третьей прошивки не будет просто потому что упрусь в ограничения самой меги - и здесь либо отступлю от постулата и впаяю 128ю мегу… либо подниму вопрос в “Самодельном передатчике” о создании новой платформы для которой я буду писать прошивку (сам я железо вряд ли буду паять…)

На rcgroups я не смогу писать (я не знаю английского или немецкого) - да и если смогу написать (translate.ru никто не запрещал) - общаться полноценно вряд ли смогу - а значит не смогу осуществлять полноценную поддержку (ошибки как видно из моего блога- все равно выявляются, и я доволен той скоростью с которой мне удается их исправлять) - а продукт без поддержки - это плохой продукт…

в отдельную ветку здесь - не знаю… стоит ли ? первая версия прошивки тупиковая в плане алгоритма… развивать ее я не буду… только исправлять ошибки… все кто ее зальют - всегда получат здесь максимально возможную поддержку…

ветку для новой прошивки (V2) - может быть попозже… если честно боюсь я как то сильнопосещаемых веток форума… привычка у меня к “камерной” работе с единомышленниками 😃

Кстати сделать свободнолетающий планер на второй версии будет реально… этот функционал реализуется условными микшерами и 5ю внутренними таймерами… - ранее о таком использовании функционала я не задумывался… но сейчас прочитав вашу задачу проверил реализуемость на второй версии - можно реализовать… правда время автоуправления будет ограничено примерно тремя минутами (с посекундным заданием программы)

Подход реализовать “все и вся” - очень тяжел - я с этим столкнулся в первой версии когда пошли пожелания по старту\останову таймера - действительно тяжко… всегда найдется тот кому нужен будет 3,4,5,6ой вариант который я не сделал… - поэтому во второй версии я задумал универсальный механизм задания логики поведения передатчика и модели - это будет еще не макроязык (нет итераций в обычном понимании), но уже достаточно развитая система условий \ выражений и выполняемых в зависимости от них действий…

такую логику я пока не увидел ни у одного передатчика (немного есть у футабы8 в части назначения событий управления таймерами) - поэтому скорее всего вторая версия прошивки будет немного сложновата для освоения новичком после “обычных” аппаратур, для тех же кто пробовал МСВ\Thus\VCoder нововведения будут только приятны, и возможно даже желанны (из разряда пожеланий о которых думают, но не говорят вслух потому как этого нигде и ни у кого нет)…
опять таки документацию для второй версии я планирую писать сразу (чтобы небыло разрыва между функционалом и описанием)

Русский язык - у меня очень много людей которые высказывают его необходимость… при желании потом можно будет сделать перевод на английский… наоборот не делаю потому что английские сокращения на экране короче русских - поэтому лучше сначала все разместить на русском, а уж на английском точно получиться не хуже… 😃

применять RC-OS смысла не вижу… итак памяти мало… тем более у нас же не 128ая мега, я все таки не оставляю надежды использовать только стандартную конфигурацию оборудования… а оставшееся место во флеш памяти использовать для хранения моделей… в первой версии кстати свободно около 10 кб… - это еще около 30-40 моделей !! (но в первой версии этого кода нет… хочу его написать для второй версии)

По поводу логики, которой нет ни у одного передатчика - есть еще что посмотреть… Старый, добрый мультиплекс серии профи 4000 … Его функционал вроде бы никто не повторил, и несмотря на старость (сродни дерьму мамонтов) он досих пор уважаем и востребован в определенном (правда достаточно узком) кругу моделистов. А узкий круг наверное потому, что конфигурить его без компа - практически нереально, чтобы не запутаться в наворотах - надо все настройки долго обдумывать и записывать на бумажке. Ну и плюс (точнее минус) - то, что в силу его старости - проявляются болячки схемотехники. Энергонезависимой памяти тогда еще небыло, пзу - не знаю почему использовать не стали… Короче - прошивка у него лежит в статической озушке, которая питается от литиевой батарейки. Батарейки свое отживают, менять “на горячую” не все могут и эти передатчики вымирают.
Но разговор не об этом. Рекомендую поискать на него инструкцию и посмотреть что он может. Возможно передрать что-то из него. Удачи!

спасибо, обязательно гляну… (у меня уже коллекция всяких мануалов 😃) и действительно очень полезно их читать)

Чувствую, начинается интересное и серьезное “кино”… Задумки многообещающие…
Что ж, хочется пожелать, чтоб все это реализовалось в “рабочую” версию…

очень ждем.

Еще хотелось бы дружелюбный интерфейс. Чтобы мозг не сломать что-то настраивая.

вот над этим сейчас и ломаю голову…
уже перебрал 2 способа меню…
к сожалению чтото изобрести пока не получается… скорее всего будет движок меню от первой версии (удачно там функционал добавляется)
Сейчас думаю как сделать удобным редактирование параметров, общая задумка такова - заходим например в микшеры, выбираем получатель - получатель это просто канал (их будет как и в первой версии 16)
выбираем источник - при этом как бы проваливаемся в новое меню - где будет выбор канал, функция, выражение, если это выражение или функция- то опять проваливаемся - и выбираем либо можем создать прямо от сюда…
сейчас вот думаю над организацией стека вызовов (чтобы как по подпрограммам через call ret работать) с глубиной где то 10 вызовов наверное…

скоро наверное можно будет выложить болванку…

вопросик маленький - а насколько нам в имени модели нужны маленькие буковки ?

будут знаки (всякие + - ? и так далее), латинские большие буквы (A…Z) и русские большие буквы (А…Я)

в принципе я могу сделать и все буквы - но возникают две проблемы - мелкая и только моя: как все разместить на экране (сливаться будут буковки и знаки) и проблема ваша: задание букв для имени модели будет занимать большое время, так как придеться перебирать большое число букв…

кстати, навигацию по выбираемым буквам сделать 4мя кнопками или сделать как в первой версии (вверх\вниз смена позиции для печати буквы, и вправо\влево - смена буквы) ?
или четырьмя (влево\вправо, вверх\вниз) кнопками двигаться по выбираемым буквам, а смену позиции сделать автоматом или специально выделенными позициями служебных буковок (типа “пробел”, “удалить”, “ввод” ?

навигацию по буквам по старому вполне удобно. мелкие буквы нафиг не надо. не письма же любовные строчить на аппе… 😃

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

не не нужно маленьких букв, желательно оставить как в старой прошивке

ОК.

Давно тебя небыло Степан! 😃

В общем набор символов будет такой:
0 1 2 3 4 5 6 7 8 9

• • ! № % * / .
    Q W E R T Y U I O P A S D F G H J K L Z X C V B N M
    А Б В Г Д Е Ж З И Й К Л М Н О П Р С Т У Ф Х Ц Ч Ш Щ Ь Ъ Ы Э Ю Я

Чтото нужно добавить/ убавить ? может быть в знаках оставить “+”, “-”, “*”, “/”, а остальные убрать ?

Занят был сильно, моё мнение знаки типа % ! + / № можно убрать, ведь как мы назывем модель в передатчике мой пример

MANTA-01
ULTIMATE
KATANA

Так что минус лучше оставить для черточки.

ОК, плюс тогда тоже оставлю… может кто нить назовет модель “ПЕРВАЯ+МОЯ” 😃))

В имени модели буду делать 10 символов… а то мне 8 иногда мало было…

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

к сожалению это обещать не могу… дело в том что модель перед сохранением упаковывается и записывается в новое место…
таким образом еепром перезаписывается равномерно по всему объему и не возникает ситуации что например начало еепрома уже по 1000 раз писали а конец еще ни разу…
в принципе могу подумать над автосохранением модели при изменении каждые 10-20 секунд…

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

ладно, пожелание я понял… подумаю как лучше сделать…

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

я так понимаю, при данных алгоритме и идеологии прошивки малость проблемно это сделать. опять же проблемы с выдачей ппм при сохранении. а сохранять привыкнете, мне тоже не нравилось сначала, счас - нормально. все равно таймер жизни модели обновить - надо в меню заходить, а при выходе сохраняетесь. и eeprom целее будет…))

не на столько эта проблема с сохранением триммеров серьезная… по моему мнению…
Как бы Виталий не запутался в наших пожеланиях… ))))
Хотя, все, конечно, на усмотрение разработчика…

турнига и приемыши -10 на хс…
наверное закажу сейчас себе…
когда еще будет такой шанс

заказал аппаратуру и 3 приемника 😃))

Народ кто может рассказать про точечные микшеры?
прочитал вот такое в форуме про аврору: “Аврора предусматривает абсолютно любые миксы “канал-канал”, хоть линейные хоть точечные(точечных правда 3 или 4 всего штуки допускается)”

интересно как это ? и насколько это нужно?

имхо имеется ввиду следующее:
линейный - uprate, downrate, offset (коэффициенты в обе стороны, смещение)
точечный - кривые по произвольным точкам.

иначе говоря, ничего необычного.

Виталий а будет выбор режима таймера как считать на прибавление или убавление?

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

в двойке будет 5 таймеров…

Извеняюсь! Может не тактичный вопрос? А как и чем прошивать??? Если можно ссылочку.

в двойке будет 5 таймеров…

ААААА!!! хачу !!!😆😉😇

в двойке будет 5 таймеров…

и один из них - время жизни аппаратуры…
и чтоб если в режиме countdown, чтоб на нуле не останавливался, а дальше считал…
можно ?.. 😒

первое (время жизни аппы) как то по другому делать буду…
а на счет остальных - сами будете режим для них выбирать…
а на счет режима countdown - немного не так будет…
просто программируете один таймер на отсчет назад (например с 5 минут до нуля)
а второй таймер программируете на отсчет вперед (от нуля до бесконечности)
ну и ставите событие на нулевое значение первого таймера (чтобы звук например подать)
а второй пусть считает… до события например остановки таймера или еще может какое зададите…
это всего 2 таймера…
3-ий можно использовать на счет во время работы двигателя (условие thro>5%)
4-ый - время полета в максимальными расходами
5-ый - ну сами придумайте наконец что нить ! 😃))

вот такая вот идея у меня по таймерам… - вы сами будете события и поведение по таймерам задавать… так что надеюсь что вопросы типа " а можно сделать …" - будут решаться только настройкой модели а не дописыванием прошивки…

забыл добавить - таймеры теперь будут входить в параметры модели… так что настраивать можно будет для каждой модели свои таймеры и свои события на них вешать…

Сергей Солоденников (AlcoNaft43) прислал в личку:

Вот набросал минимум вертолетных функций

Минимальные требования к аппаратуре для полетов на электровертолету
​

1. Выбор типа тарелки
2. Режимы полета - Normal, IDLE1, IDLE2, HOLD
3. Для каждого режима полета настраивается кривая газа и кривая общего шага по 5 точкам. В холде кривая газа = 0
4. Холд отдельный переключатель, обычно слева верхний/крайний. Режимы полетов - слева, холд имеет приоритет.
5. Настройка чувствительности гироскопа через меню, не крутилкой, ибо ее можно сбить. Настраивается для каждого полетного режима, ибо разная частота вращения основного ротора может требовать разной чувствительности. Легкий доступ для настройки при настройке в поле. Настраивается в процентах.
6. Таймер, работающий когда канал газа > 0. Причем именно не стик газа, а канал. Этого даже нет в футабе. Легкий сброс таймера, возможно тумблером.
7. Сабттримы для регулировки горизонтальности тарелки при среднем положении машинок
8. Реверс каналов
9. Регулировка конечных точек для регулировки параллельного хода тарелки перекоса
10. Микс тарелки перекоса. Настраивается направление перекоса тарелки и ее величина, в зависимости от движения правого стика и стика общего шага/газа. На футабе в некоторых мифических процентах, отрицательных и положительных.
11. Дуалрейты и экспоненты по вкусу.
12. Swashring - опция, позволяющая ограничить величину перекоса “тарелки перекоса” в крайних положениях стиков. Те если мы загоним, к примеру элеватор и элерон в угол одновременно, тарелке перекоса приходится очень туго, в реальном смысле. Но в тоже время когда лишь один стик в крайнем положении, то все ок. Принцип работы просто представить если поставить накладку с круглой дыркой на правый стик, при 2 моде. Есть только в продвинутых аппах, начиная с Футабы 8.
13. Для бензиновых вертов еще нужен Throttle Cut на отдельной тумблере, хотя вряд ли на бензиновом будут летать с такой аппой 😃

Жду ваших комментариев, пожеланий относительно написанного (я рад что появился такой четкий и более менее достаточный список функций для вертолетов)

В холде кривая газа = 0

чтобы не плодить сущностей, HOLD — просто еще один полетный режим, в котором кривая газа обычно задается “полочкой”. только вот высота этой полочки должна регулироваться обычным образом, не всегда она равна нулю, у двс глушить движок в полете — плохая идея ;)

Настройка чувствительности гироскопа… Настраивается в процентах.

опять же, зачем проценты, +/-100% это 200 градаций, аппа поддерживает 1024, зачем же терять в разрешении?

Swashring… Есть только в продвинутых аппах, начиная с Футабы 8.

дык там и процик вроде как помощнее. считать на лету синусы/косинусы текущая прошивка успеет? тут нужен некий упрощенный алгоритм, типа замены расчета экспоненты на несколько умножений. то есть не обязательно получить на выходе идеальную окружность, вполне достаточно будет 8-ми угольника (упрощенно говоря).

Режимы полетов - слева

не совсем понял, в аппе этот тумблер справа.

Микс тарелки перекоса.

тоже непонятно, для чего микшировать AIL/ELE с шагом, но это ведь банальный микс который доступен даже в оригинальной прошивке.

Виталий насчет таймеров понравилось - всмыле старт второго по стопу первого. Насчет остальных таймеров я думаю каждый найдет им применение.

Жаль насчет вертолетов ничего не могу посоветовать я в этом неразбираюсь.

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

сбрасывать вручную не обязательно… можно сделать контроль прежнего значения батареи и если оно увеличилось то сбрасывать счетчик (значит либо зарядили батарею либо поставили новую)

Да хотел об этом попросить но подумал зачем еще программу напрягать

😃 а напрягать и не придется… эту проверку делать нужно при старте прошивки… так что по идее ничего и не поменяется в части нагруженности…

Мультиплекс считает съеденный ток.

гм… ну в принципе ток потребления наверняка берется усредненный…
так что умножить время в сек. на ток чтобы посчитать потребленную мощность - в принципе можно…

Так ведь не точно это будет… Разные модули - разное потребление. Причем намного. Если есть какой-нибудь сенсор в этой аппе по току (в чем я сомневаюсь), или если данные по потреблению можно снять, тогда да… А так - есть ли смысл делать нечто с очень примерными данными, на которые все равно нельзя ориентироваться…

есть ли смысл делать нечто с очень примерными данными, на которые все равно нельзя ориентироваться…

Абсолютно согласен. Разве не хватает контроля и индикации напряжения на аккумуляторах? Если заряд у них на пределе, то все равно летать не стоит, и не важно на сколько осталось заряда - на 5 минут или на 7.

Тут это… другой вопрос…
Можно ли (насколько сложно) реализовать мультиплексирование каналов ? Надо ведь еще дешифратор делать … Может кто обладает информацией по данной теме - подскажите, или посоветуйте что-нибудь… Есть ли ограничение по модулю ВЧ - приемнику, или любой комплект эту штуку проглотит ?
Было бы вообще супер. Виталий, кажется у тебя были мысли на эту тему ?.. Не забросил эту идею ?..

Нет конечно !!

Мультиплексирование можно сделать на любом приемнике и модуле…
В VCoder’e есть функционал мультиплексирования со стороны передатчика, накидывал схемку приемника - но не закончил к сожалению… - буду во второй версии делать тот же алгоритм мультиплексирования каналов что и в первой и потом все таки планирую заняться приемной частью…
Фактически демультиплексор это мега8 (ну сейчас наверное мега88) с кварцем - включается в один из старших каналов приемника и на выходе дает еще 3-4 канала…

Потихоньку возвращаюсь к написанию двойки (время появилось)

вот за несколько дней набросал меню (в принципе от VCoder’a взял)
ну и редактор имени модели vcm.hex.html

больше ничего не работает…

предложения по редактору имени модели (например по набору символов) или по меню принимаются к рассмотрению

В этой прошивке ничего больше не работает (видимо по крайней мере).

p.s. если будете перепрошивать “боевой” передатчик с моделями не забудьте сохранить свой еепром от своей версии прошивки !! иначе потеряете их !!

Ждёмс

ОК.

РЕДАКТОР КРИВЫХ

Предполагаемый набор функций
0. выбор номера кривой (возможно задание 16 кривых)

1. предустановленные кривые:

• выбор предустановленных кривых (какие варианты нужны?)

2. пользовательские кривые

• выбор количества точек кривых от 2х до 9 точек
• задание точек

Используемые кнопки - кнопки навигации по меню + menu + exit

размер экрана 128 на 64 точки
в принципе можно разбить функционал на 2 экрана (ну может быть и на 3) - главное условие понятность интерфейса !

размер символов 5х8
при выделении к первому символу слева добавляется один пиксел

Нужно:
где что располагается, какими кнопками, как изменяется, как эт изменения отображаются

Приму в любом более менее понятно-читаемом виде

готов ответить на любые уточняющие вопросы

кстати - голову сломал - насколько нужно иметь возможность задавать положение точек кривых по горизонтали (входное значение) или достаточно их разбросать равномерно от -100 до +100 %% ?

то есть первый вариант, например, можно задать 3 точки
первая точка задается в позиции -100%
вторая точка в позиции -50%
третья точка в позиции +100%

во втором варианте три точки будут автоматом помещены в позиции -100, 0, +100 %% без возможности их двигать по горизонтали…

так вот - насколько нужен первый вариант, или второго с заданием произвольного количества точек “за глаза” ?

Если количество точек можно задавать, второго варианта хватит. За глаза.
Хотя если кривая ломаная и без сглаживания - тогда не знаю… Может кому такие нужны …

Органы управления
У каждого органа управления будет 2 параметра - значения минимума и максимума, для дискретных каналов генерируемое значение либо мин. либо макс. д

Предлагаю предусмотреть для дискретных каналов минимум 3 значения. Если кто захочет сменить 2-х позиционный переключатель на 3-х позиционный!

если даже захочет сменить - то все равно свободных ног у меги можно сказать что нет 😦
так что не выйдет у него ничего…

кстати условиями можно будет делать любое количество значений исходя из входящих значений нескольких выключателей

если даже захочет сменить - то все равно свободных ног у меги можно сказать что нет 😦
так что не выйдет у него ничего…

кстати условиями можно будет делать любое количество значений исходя из входящих значений нескольких выключателей

А зачем свободная нога меги? разве любой тумблер или любой стык не на одно АЦП подается?
Я имел в виду, что на канале тумблера иметь не только два крайних положения машинки но и середину. Вроде достаточно коммутировать 2-3 резистора.

кстати - голову сломал - насколько нужно иметь возможность задавать положение точек кривых по горизонтали (входное значение) или достаточно их разбросать равномерно от -100 до +100 %% ?

то есть первый вариант, например, можно задать 3 точки
первая точка задается в позиции -100%
вторая точка в позиции -50%
третья точка в позиции +100%

во втором варианте три точки будут автоматом помещены в позиции -100, 0, +100 %% без возможности их двигать по горизонтали…

так вот - насколько нужен первый вариант, или второго с заданием произвольного количества точек “за глаза” ?

-100, -50, +100 как-то не симметрично тогда -100,-50,0,+50,+100. Или -100,0,+100.
Вообще-то кривые, наверное, интересно настраивать в пределах -70…+70, мое ИМНО! т.к. на крайных положениях стыков полет проходить редко! думаю 5 точек достаточно. Лично я кривые применяю для предотвращения дёргания модели при управлении около нулевых положении стыков. т.е. это важно при заходе на посадку. У вертолетчиков естественно своя точка зрения.

насколько нужно иметь возможность задавать положение точек кривых по горизонтали (входное значение) или достаточно их разбросать равномерно от -100 до +100 %% ?

Мне кажется, что здесь определяющим фактором будет размер флеша и епрома у меги. Неравномерное расположение точек потребует запоминания еще одного массива байтовых значений скорее всего приростов (расстояний между точками). Плюс усложненное редактирование. И если будет введена 9-точечная кривая, то наверняка будет очень трудно заметить разницу в поведении модели с равномерным и неравномерным расположением точек. Я бы делал равномерно.

Предлагаю предусмотреть для дискретных каналов минимум 3 значения. Если кто захочет сменить 2-х позиционный переключатель на 3-х позиционный!

Вообще-то по идеологии дискретные выключатели для того и двухпозиционные, чтобы что-то включить либо выключить. Введение третьего положения внесет сильное усложнение кода и настройки. Если кому будет нужен трехпозиционный (либо на больше позиций) переключатель, то его надо будет делать вместо крутилки. Т.е. крутилка как бы будет иметь несколько предустановленных положений. А учитывая то, что будет реализована логическая математика, то можно будет через нее реализовать например 4 положения закрылков от двух дискретных переключателей.

как вариант 4 положения закрылков от крутилки 😃 причем можно сделать банально кривыми…

ПО КРИВЫМ
Тогда останавливаемся на изменении только количества точек кривых, точки раскидываются равномерно по всему диапазону от -100 до +100 %%

И двухпозиционные переключатели от -100 до 100, а не от 0 до 100. Так по моему, логичнее…
На многих аппах именно так сделано…

по тишине я понимаю что интерфейс никто не предложит … 😦

С удовольствием поделился своими соображениями по поводу интерфейса, но я ещё не заливал VCoder2

по тишине я понимаю что интерфейс никто не предложит … 😦

Нет возможности попробовать 2 версию, но по кривым предложение такое. Рисуем сетку (горизонталь - только мах, мин и нулевое, вертикали - только где Х точек. Клавишами влево-вправо подганяем указатель-стрелочку под нужный Х, а клавишами вверх-вниз смещаем У данной точки. Сбоку от сетки нужно писать числовое значение У. И можно даже сразу после сдвига перерисовать сетку и кривую. Выходим из редактирования по Exit.

угу… так в принципе в первой и сделано…

Ждём с нетерпением функционирующей прошивки.

угу… меня тут пробило немного опять… сижу пишу 😃
сделал немного отличающийся механизм изменения простых параметров сейчас отлаживаю (почему то двойное нажатие exit регистрируется вместо одинарного… разбираюсь)

вот такой вариант редактирования параметров vcm.hex.html

смотреть в меню
Настройка передатчика - Навигация по меню - Задержка навигации

вотс… vcm.hex.html

в меню “настройка передатчика” уже можно играться некоторыми настройками:

• задержками при навигации по меню
• задержками при изменении значений
• звуком при навигации по меню (при 0 звука нет)
• звуком при изменении значений (при 0 звука нет)
• контрастом дисплея
• общим выключателем звука

юзабельность можете обсуждать в принципе можно еще подсказки (какие?) воткнуть в пункты - только скажите какие и куда

кто нить может скинуть резюмирующую информацию по форматам сигналов ппм для различных вч модулей ?
интересуют следующие настройки:

• формат (позитив / негатив)
• общая длина пакета (18,5 / 20 / 22,5 мс)
• количество каналов в пачке
• минимальная длительность канала в мкс
• максимальная длительность канала в мкс
  середина в 1500 мкс вроде у всех ?

все эти настройки будут объединяться одним общим именем и будут выбирабельны для моделей
всего таких настроек будет штук 5… пользовательских из них наверное 2 или 3… (Смотря сколько накидаете стандартных)

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

У меня когда была стандартная турниговская прошивка работало и с прямым и с инверсным PPM на модуле Корона. Других модулей нет так что помочь в этом плане немогу.

А что, предполагается использование одновременно нескольких ВЧ-модулей?

Не то, чтобы часто и постоянно, но я, например, иногда меняю. А теперь еще один модуль появился… Так что “частота” смен возрастет…

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

ну по экспонентам вопрос еще будет задаваться… 😃 так что сможете поучаствовать 😃

а на счет ВЧ модулей - многие уже меняют стоковый и на FrSky и на Spektrum DSM2… так что настройка ВЧ модуля точно не помешает

ну по экспонентам вопрос еще будет задаваться… 😃 так что сможете поучаствовать 😃

С удовольствием.

Виталий, тут нарыл такую штуку - code.google.com/p/eepe/, внешний редактор моделей. не было мыслей по этому поводу? слил eeprom, отредактировал, тут же проимитировал, если устраивает - залил обратно.
соответственно весь функционал предустановленных кривых/микшеров/настроек можно вынести в программу. хотим бы, например, дефолтный биплан с раздельными элеронами и закрылками — жмак кнопочку, на выходе готовый набор миксов. хотим настройки для верта с 140°-ной тарелкой, опять жмак, одновременно визуализируем саму тарелку, ну и так далее.

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

гм… на счет внешнего редактора думал. даже где то запрашивал программу которая может .bin в .hex и обратно перегонять…

кстати идея на счет базового редактора хороша !! (не додумал до этого) потому как уже сейчас в двойке тяжко с памятью программ 😦

Что то подозрительная тишина, может скоро выйдет новая версия ))))

Что то подозрительная тишина, может скоро выйдет новая версия ))))

Думаю, просто у Виталия совсем нет времени, в связи с новой работой…

Эхх… Дмитрий, ты прав… вообще редко стал бывать на форуме…

А вот двойку потихоньку пишу 😃))

тут мне как раз пришла вторая аппаратура - вот на ней двойку и обкатываю…

ждём

Виталий как прогресс с V2?

Не помешала бы еще одна фича - замедление отработки серв. То есть возможность сделать закрылки, шасси, бомболюк итд без применения специальной платки в модели. Ибо лишняя платка - вес, деньги и главное, время, пока ждешь ее.
Дело в том что ко мне едет аппа, и скорее всего буду ее перешивать после ознакомления.

sashaNar замедление есть в англоязычной прошивке. Тема Наш ответ Китаю

Да, конечно замедление будет… как и прежде любого канала при изменении в каждом направлении…

Виталий. Вы говорили о том что в вашу программу телеметрия впишется как родная. Хотелось бы чтоб было звуковое оповещение о превышении параметров. Например-увеличился ток двигателя до предельного звучит голос -перегрузка. Или просто пищание какимто тоном отличающегося от других. Упало напряжение-пора на посадку. И.Т.Д. Извини -на каком этапе разработка можно на нее расчитывать?.

это все реализуется заложенными возможностями программирования модели… будет там телеметрия или нет - это уже дело второе… для тех у кого телеметрии не будет уже заложил функцию расчета остатка заряда батареи (в зависимости от активности работы стиком газа)

Двойка пишется медленно… сейчас дописываю редакторы параметров - параллельно еще раз прорабатываю в голове процессор модели (который по параметрам будет ее обсчитывать)…
Так что пока смотреть особо нечего 😦

ЭЭЭЭ, редактор форматов ппм уже написан…
храняться форматы для 3х ВЧ модулей…

если у кого есть возможность - нужны рабочие параметров ВАШИХ ВЧ модулей…
интересует следующий формат данных (наверное кидайте в виде таблички прямо сюда)

Название модуля - не более 8 символов, лат\рус буквы, цифры, знаки
Полярность сигнала - негатив\позитив
Длительность пакета - 18,5; 20,0; 22,5; 25,0 ms - в принципе можете этот параметр не заполнять… по умолчанию будет 20,0
Минимальная длительность канала - 619…1384 мкс
Максимальная длительность канала -1619…2384 мкс

в принципе от вас интересует полярность сигнала и длительности…
полярность - в меню SYSTEM
Длительности- практические значения длительности канальных импульсов при которых сервомеханизм еще отрабатывает сигналы приемников… - поэтому и интересуют связки ВЧ-передатчик, Приемник, сервы…
Для тестов можно использовать VCoder, в меню EDIT- LCH SET - LCH EPA задаем тестируемые длительности каналов и пробуем на приемнике… (в принципе даже не нужен самолет, достаточно к приемнику на столе подключить регуль и серву… ну к регулю батарею не забыть 😃)
у меня на тестах с ВЧ Eurgle при превышении длительности канала - машинка шла в край а потом возвращалась в центр (значит превышен импульс) - что у вас получилось ?

Нужна статистика… очень жду ее…

Подумал тут еще об одной функции. Вроде как нет еще ее. (?) Не знаю можно ли ее реализовать программно - настройка вольтажа при котором начинает пищать и при котором вырубается. Слышал, аппа отлично работает от 2х банок липы только пищит отчаянно при этом.

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

Аларм по понижению напруги уже есть. А вырубалку программно не сделаеш - надо железо курочить (добавлять электронный ключ либо менять регулятор напряжения на регулятор с шутдауном), что в данном проекте пока не рассматривается. Да и не выдержите Вы долго постоянного писка аларма 😉

Подумал тут еще об одной функции. Вроде как нет еще ее. (?) Не знаю можно ли ее реализовать программно - настройка вольтажа при котором начинает пищать и при котором вырубается. Слышал, аппа отлично работает от 2х банок липы только пищит отчаянно при этом.

Аларм по вольтажу с заданием порога есть в VCoder, в двойке будет тоже самое, так что хоть 2е банки лития, хоть 7 банок кадмия 😃 пищать не будет 😃
Только калибровочное значение подобрать точнее нужно чтобы значение на экране было точным - а то аппа сама вырубается при чтото около 7 вольт (возможно что индивидуально)

у моей аппы при 7,2 вольта вырубается

гм… значит мне повезло больше… Юрка вырубилась у меня при 6,9… проверял по показаниям вольтметра…
а вот турнигу V2 еще не проверял…

У меня тоже - запитал FlySky от двух банок, откалибровал, насколько возможно, выставил аларм на 6,9 В - аппа вырубилась раньше, чем сработал аларм. Скорее всего, надо менять кренку в аппе на лоу дроп, типа КР1158ЕН5.

Ф-ию тестирования серво - плавное движение от мин. до макс. и тест нейтрального положения возможно добавить?

Ф-ию тестирования серво - плавное движение от мин. до макс. и тест нейтрального положения возможно добавить?

+1

а “тест нейтрального положения” - это как ?
сначала сдвинуть в любое (случайное) положение и потом вернуть в нейтраль ? (и так несколько раз)

а “тест нейтрального положения”

Про тест нейтрали тоже не совсем понятно, а вот плавно от минимума до максимума в цикле - весьма полезная вещь. А если еще тестируемые каналы можно будет выбирать (какие-то вкл, какие-то выкл) - вообще здорово будет.

Очередная игрушка… vcm.hex.html

Сделаны:

Настройки передатчика:

• Настройки навигации по меню (реакции на нажатие кнопок меню)

• Настройки органов управления:
  А) выбор моды (1,2,3,4)
  Б) просмотр результатов калибровки
  В) калибровка аналоговых каналов

• Настройка контрастности дисплея

• Общий выключатель звука

• редактор форматов сигнала ppm (для трех внешних модулей)

Настройки модели:

- редактор имени модели

• редактор используемого внешнего модуля в модели

• редактор количества используемых физических каналов

• редактор констант и переменных

• редактор значений органов управления

• редактор каналов с возможностью задания 5ти средних точек

Буду благодарен за тестирование написанного, указание на ошибки и неточности.

По стикам решил их назвать по функционалу, так появились следующие органы управления: Крен, Тангаж, Тяга, Направление - думаю что это лучшее решение… настройки моды передатчика будут приводить любую физическую конфигурацию стиков к этим параметрам…

в правом верхнем углу выводится текущее значение быстродействия главного цикла… пока цифры радуют, процедуры в цикле “умудряются” сработать до 700 раз в секунду !! - все таки не зря я озадачивался скоростной оптимизацией… конечно эти значения сильно упадут когда дойдем до математики каналов, но радует то что не теряем процессорного ресурса скорости вычислений на работу с LCD

p.s. как же мне мало 64-ой меги !! уже вошел в режим экономии и попытки оптимизации всего и вся 😦(((

p.p.s. начинаю ненавидеть написание интерфейсов 😦 эти выводы меню, обработка нажатий кнопок и т.п. 😦(( все таки как было хорошо в первой версии VCoder’а - там движок меню брал всю работу по редактированию списков и параметров на себя… да, конечно не экономно с точки зрения расходования программной памяти - зато очень экономно с точки зрения нервов и времени на отладку…

Виталя, то ли ишшо буит… … а вообще возможности паршивки думаю будут шикарными… и про память… на крайняк придется таки мегу 128 использовать …

пока все таки надеюсь что смогу оптимизируя уместить все в 64ю мегу - если же нет то скорее всего я озадачусь внедрением в аппу второго процессора… уже есть мысли о разделении процессов работы с дисплеем и опроса органов управления от процесса обсчета каналов… - его можно будет повесить на вторую 64-ую или даже 128ую мегу…
достоинство такого решения - для модернизации не нужно будет перепаивать мегу (я например дома сам вряд ли смогу - нет ни паяльника, ни желания это делать) - в моей задумке нужно будет всего лишь навсего припаять в определенные места 7 проводков - что всего на 2 проводка сложнее чем припайка разъема для программирования 😃))

гут!! ждемс!! 😃

…в моей задумке нужно будет всего лишь навсего припаять в определенные места 7 проводков - что всего на 2 проводка сложнее чем припайка разъема для программирования 😃))

Вот это задумка ! Можно хотябы в общих словах ? Это как так ?

Я, как любитель подымить паялой конечно с надеждой смотрю на появление второго CPU в корпусе аппаратуры, согласен даже состряпать статейку по такому модулю и изготовить и выслать его вам за просто так. Но возможно, я совершенно не понимаю о чём идёт речь (переоцениваю свои силы) и что именно нужно делать со стороны аппаратных ресурсов. Только погружаюсь в это мутное озерцо аппаратур. Пока, я разобрался только с питанием. 😦

На мой взгляд, стоит сделать второй проц. У проекта появится второе дыхание. Виталий, вы как программист сможете больше думать о функционале, а не о том, где бы ещё скостить десяток байт памяти программ. Тупик наверняка вот, он… дышит уже в спину. Обидно будет, если раком встанет всё. Это конечно немного эгоистично, но если возможности аппаратной системы уже исчерпаны - то может стоит согласиться с тем, что надо что-то менять при помощи паяльника ?

… - его можно будет повесить на вторую 64-ую или даже 128ую мегу…
перепаивать мегу (я например дома сам вряд ли смогу - нет ни паяльника, ни желания это делать) -

Второй процессор это значительное усложнение аппаратуры, и доп. печатная плата.
Жал вы не в Москве, перепаять процессор не проблема. Надеюсь в ваших краях найдете специалиста.
Если надо будет помощь в разводке и изготовлении ПП, обращайтесь, помогу.

дык в том то весь и фокус !
у второго проца из навесного фактически только кварц с двумя кондерами !! (за что я люблю меги - так это за их самодостаточность!)
все органы управления остаются на первой, уже впаянной в аппу меге !

использование памяти меги в VCM уже достигло 45 %… написано процентов 70 интерфейса…
наверное для дополнительного flash диска места совсем мало останется 😦

использование памяти меги в VCM уже достигло 45 %… написано процентов 70 интерфейса…
наверное для дополнительного flash диска места совсем мало останется 😦

Виталий, а может просто переместить всю память на отдельную епромку и не городить со вторым процессором? Мне кажется, что разделение программы на два независимыъ вычислителя достаточно напряжное решение. Сразу возникнут вопросы обмена данными и синхронизации работы. Я когда-то таким занимался 😦 . Да и кода для этого прийдется написать немало. Так что я голосую за епромку.

Есть SPI в режиме Full Duplex на завидной скорости обмена. Есть на него прерывание, которое будет очень небольшим. Можно заставить один из процов собирать все данные, отправлять их по SPI и заниматься вопросами интерфейса. Второй проц может взять на себя задачи конечной обработки/формирования пакетов. Успешность выполнения такого проекта будет во многом зависеть от возможностей деления/распределения функций двух CPU.
Как бы их так поделить - чтобы обмен по SPI был однонаправленным…?

Как мне показалось, если взять рядового человека умеющего паять и что-то травить на текстолите, то задача протравить плату под второй проц и впять его будет выглядеть меннее травматично для модернизируемого изделия нежели перепайка проца. Просто, я знаю что при неумелой перепайке люди порой гробят дорожки на модернизируемом аппарате. И с оглядкой на это - некоторые просто боятся заниматься такими извратами. Качество удержания дорожек некоторорыми текстолитами из поднебесной - часто оставляет желать лучшего. Но бывают и исключения. Да, надо найти спеца, надо запастись правильным инструментом и материалами… Но с другой стороны, на втором CPU нам даже плату можно трассировать на халя-баля… у него выводов то бует: раз, два и обчёлся. Индикатора нет, кучи входов АЦП- нет, будет выход, SPI, питание, кварц и… туча пустых портов. Приклеить мини-плату с процом на заднюю стенку аппаратуры на термопистолет и всё. Если что - плату выкинул, “стандартную” прошиву залил и ты никак не испонганишь ни дорожки, ни проц… Т.е. есть некий шанс на откат процесса. Возможно, именно это кому-то добавит смелости в модернизации.

Именно так как говорит Роман я и думаю…

причем еще раз повторю - на плате нужно будет разместить: мегу128 (или 64), 2 кондера, кварц… - все !!!
в принципе даже плата не нужна… все в воздухе чудесно повеситься… и на термопистолет или еще как закрепиться на любое удобное место…

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

Виталий, а может просто переместить всю память на отдельную епромку и не городить со вторым процессором? Мне кажется, что разделение программы на два независимыъ вычислителя достаточно напряжное решение. Сразу возникнут вопросы обмена данными и синхронизации работы. Я когда-то таким занимался 😦 . Да и кода для этого прийдется написать немало. Так что я голосую за епромку.

Проблема не в памяти… еще в первом кодере я уместил более 8 моделей. - я считаю что этого для хобийного направления аппаратуры более чем достаточно…

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

хедтрекер или тренерские функции или телеметрия - все таки интересны мне и я хочу их вживить…

в двойке алгоритм генерации сигналов будет другой… посмотрим что будет… а там и решим…

просто дополнительно еще и программа сильно разраслась. все таки функций напихал туда тучу !!!

Виталь, эси оченна надо - готов те травануть , впаять и отправить мегу 128… тока дай схемку на какие ноги выводы делать… и какой кварц на нее повесить…

Платы… платы… платы…

Смотрите что я нашел, для меня - было откровением что такая удобная штукень есть (возможно, кото-то тоже не видел)

Описание:
“Двусторонняя макетная плата MTR248 с металлизацией отверстий, стеклотекстолит 1.5 мм., шаг отверстий = 1,27 мм. Размер платы = 40х40 мм. 1-я и 2-я стороны разные.”

цена: 45 руб (даже три раза на автобусе не проехать…)

Ссылка на товар.

Это не реклама. Это просто попытка показать - что всё уже есть и делать ничего не надо. Стоит - смешно.
Ой…! Вернее длать надо много, но в программе. 😃

А чё, красиво: кварц втыкается в дырдочки… проводочки - тоже, да кондёры под кварц будет куда удобненько прицепить. А с обратной стороны - так вообще россыпон из SMD можно “насыпать” если вдруг припрёт что-то сильно.

Софт… софт… софт… - вот наше всё…

Роман, эт конечно здОрово что такие штуки есть на белом свете… но вот к примеру мне до ближайшего магазин, где эту платку купить мона надо на машине 200 км пропилить… поэтому прощще травануть и не париться… хотя за фотку спасибо… кое на какие мысли наводит… ну а касательно моего предложения Виталию - оно в силе… поскольку я в программировании практически ни бум бум то хоть таким способом попытаюсь помочь ему с аппой в ее совершенствовании. тем более что у меня в этом как бэ личная заинтересованность есть… 😉

…вот к примеру мне до ближайшего магазин, где эту платку купить мона надо на машине 200 км пропилить…

Да… далеко, полностью с вами согласен. Фирма “Десси” вроде как располагается по адресу “107113, г.Москва,…”, и мне нужно до неё ехать несколько тысяч километров. Но я туда не поеду. Я сделаю заказ по обычной почте (хавают наложенный платёж), а ещё лучше - я сам протравлю всё.
Но повторюсь, вдруг кому-то банально лень травить… или просто не умеет человек. Вот возьмёт и закажет.
Вопрос со впомогательной платой можно считать полностью исчерпаным.

• Она есть.
• Стоит копейки.
• Покупается наложенным платежём.
• Делается на <раз> <два> самим любителем.

я купил такую плату но для 128 меги…(там шаг выводов около 0,5 мм) - а так именно так она и выглядит… стоила кстати в чипе и дипе (мягко говоря не самом дешевом магазине) рублей 90…

шаг отверстий = 1,27 мм.

Пппардон…
Надо поискать с шагом 0.8мм точно такое-же изделие. Не знаю, пока не нашел.
А я почему-то был твёрдо уверен в том, что там на проце, шаг именно 1,27мм. Обшибся я.
Прошу прощения за приведённый образец платы.

Mega_128…Mega_64…
Итог: Разные процы - разный шаг.

вот она: www.chipdip.ru/product/qfp-pcb.aspx

или вот: www.chipdip.ru/product/ppo-qfp-pcb.aspx
помоему даже все таки вторая

вот она…

Вот и гламурненько !..

QFP печатная макетная плата - шаг не написан. Точно вопрос шага этой платы решится наверное только после покупки этого образца. (может, уже кто-то покупал…)

ППО QFP-0.8 36-128 выводов, печатная макетная плата - с этим вроде проще. MEGA в корпусе 64A обязана встать как родная. Т.к. шаг продекларирован 0.8мм

QFP печатная макетная плата - шаг не написан. Точно вопрос шага этой платы решится наверное только после покупки этого образца. (может, уже кто-то покупал…)

Написано на самой плате - 0,5мм

Написано на самой плате - 0,5мм

Хм… точняк ! Спасибо… заметил.

Я тут мотрю раздел “Ordering Information” в чтиве на процы Mega641_1281_2561…

Тот факт, что есть даже AtMega2561 в корпусе 64А говорит о том, что шаг 0.5мм для нашего случая переделки излишен. Т.е. нужен шаг макетки в 0.8мм. Т.е. любой проц этой линейки, можно купить в корпусе 64А. Тем более классака AtMega128A так же выпускается в “64А”.
Так или иначе, макетки добыть/купить относительно просто, и сделать их самому тоже не проблема (при должном подходе и достаточном желании).

ладно, мы чтото отклонились от темы…

кто нить может на себя взять труд по фотографированию всех экранов меню второй версии? нужно просто более менее качественно пофоткать все экраны с разрешением 640 на 480 и накидать фотки в .doc файл чтобы я мог начать составление документации (А то потом за раз все не осилю описать)… чтото можно описать и самостоятельно, если что я поправлю…

вот ссылка на свежий файлик (меню “Условия\Выражения” пока не фоторафируйте, еще пишу) vcm.hex.html

…кто нить может на себя взять труд по фотографированию всех экранов меню второй версии?

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

ну вспышка мне только мешала… блики создавала плексе…

в общем буду рад если чтото сделает мне эти фото !

ну вспышка мне только мешала…

Ещё немного отколнимся в частности… 😃
Надо её (вспыху) в потолок “упирать”. Тогда источником света станет не мелкая лампочка размером 3 см, а несколько квадратных метров яркого пятна на потолке (если он белый). Но дури у вспыхи должно быть очень много. Тогда свет пойдёт как-бы с разных сторон сразу. Но лучше правда - без неё и просто на штативе.

Шнурок на AVR ISP MkII я себе распаял. Долго вкуривал - почему у меня AVR ISP MkII сигнализирует о некорректной распайке кабеля ISP… Оказалось, что в спеках на AVR ISP MkII прописан кондёр на линии RESET не более 10uF. а там - 47uF впаян тантал. Блин… пофоткать толком ничего не успел.
В меню настройки контрастности, насколько я понял ещё недоделано ? Или уже обязано работать. а то что-то у меня не получилось поправить контрастность. Где я протупил ?

Всё. Разобрался - какого чёрта я не мог сдвинуть настройки с места. “Задержка изменеия” не давала мне этого по-умолчанию. Т.е. я привык к резким и чётким нажатиям, а она меня игнорировала. Скрутил всё на минимум (Задержка изменеия) и процесс пошел. Только что-то меня немного коробит: “Задержка изменеия” у меня на минимум и “Контрастьность” тоже. Т.е. я пробую два показателя отрегулировать и везде шкребу по нижней границе. Настораживает однако… Но работает… 😃

по пределам значений ориентируйте меня !!
многие вещи поправимы…

конкретно с контрастностью - все очень сильно зависит от аппаратуры… для турниг первой версии и например юрки - значения контрастности дисплея отличаются на 5 единиц…
крайние значения не делал чтобы не создавать экстрима в работе самого дисплея как железки… - но если будут такие желающие - то без вопросов… сделаю 😃

по пределам значений ориентируйте меня !!

По контрастности: я ввёл текущий минимум и показывает самым лучшим образом. Если ставить максимум - то вааще нихера не видать. Это у меня так. Просто, если у меня минимум - это хорошо, то может кому-то придётся ставть ниже (а там счас низя). Так может ещё -4 сделать для текущего минимума ?
Стоит попробовать.
Я - отпишусь…

Версия для фотографирования vcm.hex.html
​
ИЗМЕНЕНИЯ:

-Убран счетчик главного цикла

• Минимальное значение контрастности 15 единиц (было 25)

Минимальное значение контрастности 15 единиц (было 25)

С контрастностью - полегчало. Думаю, можно так и оставить. Диапазон тот что нужен. Врятли меньше кому-то нужно будет. Если что - объявятся и напишут.

Выложил фотки, что наклацал. Но ещё не внёс их в Word. И далеко не все там. Время - это тоже наше всё.

ух ты !!
класс !!!

как смогли так сфотографировать?!
я для первого кодера замучался фотки делать - постоянно то блики то не видно то не четко… а тут просто заглядение !!!

Роман, с твоего позволения для фотографирования меню буду обращаться к тебе !

ух ты !!
класс !!! … как смогли так сфотографировать?!

Спасибо за коментарий, а я только вот собрался просить тебя Виталий глянуть набор фоток чтобы оценить - годятся или нет по качеству. а ты сам всё глянул.
Очень хорошо что фото на уровне. Я рад. Но у меня и к этим фотам есть вопросы:

• Я не заметил пылину в левой части изображения, хотя и тёр перед съёмкой экран специальной синтетической “тряпочкой”. Прилетела падла и её глазами не видно. а вот объектив её увидел и блин совершенно честно и справедливо её везде изобразил.
• Внизу изображения имеет место теневой переход, он не мешает читаемости, но он есть и я должен был что-то сним сделать (как-то поставить свет иначе, но я пока не знаю как)
• На некоторых кадрах, пока я двигал пульт лазая по меню - есть лёгенький блик. Он - тоже гавно то ещё. Вроде я старался без них (бликов), получилось… но не до конца.

Т.е. я такое делаю первый раз. Примерно только знаю что надо, а опыта небыло. Думаю, что если бы я делал это разок так в пятый то пунктов было бы поменьше. Ну, ничего… не всё так печально.

Я веть купил вот только что аппу. Снял с дисплея защитную пленку. Так у меня аппа пробыла всего один день. Вчера, я достал защитную плёнку для КПК и решил её присандалить перед фото-съёмкой и блин заметил что акрил (или что-то там ещё) на дисплее уже имеет некие разводы или царапинки, которые я не могу свести. Я офигел ! Офигел что не успел ещё помучать аппу, а дисплей так легонько коцается. Тут же пропали все сомнения что дисплей надо срочно накрыть. Накрыл. Но понял что внутри аппы есть пыль. Т.к. разборка аппы - для меня почти как за хлебом сходить. Т.е. я всё это к чему. Не то чтобы я такой чистоплюй и терпеть пыль не могу. Я про то, что чем дальше - тем больше будет пыли на фотах, и с этой пылью очень трудно мне будет справится. И её видно что самое хреновое. Т.е. будет мануал “в пыли” … если если так можно сказать.

Как фоткать злой LCD… (оффтоп, но вопрос был задан)
Технология съёмки LCD (мой первый опыт):
Кажется нужен (как ни странно) вечер.
Обычный стул, на него кладётся горизонтально аппа.
Включаем свет в помещении. На спинку стула можно повесить тряпку чтобы свет на LCD мог попасть только с потолка (а не напрямую от лампы освещения помещения). Это вопрос эксперимента и небольших передвижек.
Рядом со стулом - ставим обычный штатив для фотика. Я даже полностью штатив не раскладывал по полной высоте.
Ставим на штатив фотик, наклоняем объектив фотика почти вертикально вниз, но до полной вертикали - немного недотягиваем (градусов 5…10).
Выключаем (или просто не ставим на фотик) вспышку.
Если есть настольная лампа (энергосберегайка) - то направляем её в потолок (должен быть белым, или желтоватым).
На фотике (очень желательна зеркалка) ставим режим “А” - приоритет диафрагмы и ставим её значение например 6,3.
Фиксируем ISO на 100 или 200 единиц.
Делаем замер экспозиции притопив кнопочку. Замечаем что там написал нам фотик в качестве времени выдержки. Запоминаем и переходим в режим “М” (полный ручник).
Ставим в ручняке диафрагму (что до этого ставили) и ставим выдержку. У меня была диафрагма 6.3 а выдержка получалась примерно 5…6 секунд.
На объективе клацаем переключателем режима фокусировки и переводим его в положение “М” (ручник). Вручную, наводим фокус.
Если есть (а если нет - то используем внутренний таймер фотика) - втыкаем пульт-кнопку в фотик, (чтобы нажимая кнопку спуска наш фотик никак не дрыгался).
иии… вдохнув, начинаем делать кадры один за другим. Если полы с досками, и они пошатываются - то в течении длительной выдержи нужно стоять крепко и не топтаться как слон, а то резкости на кадрах не будет (пыль кстати тоже расплывётся 😃)
Т.к. выдержки - конские, то в фотике надо включить шумодав для так называемых “горящих” пикселей. Это есть кажется только в зеркалках и то не во всех.
Я использовал любительскую зеркалку “Canon 5D” с объективом “Canon 24-105 F4 L”.
Фотал на фокусном расстоянии 105мм, в RAW. потом - делал crop, повышение резкости, контрастности, сохранял в JPEG, а потом ещё дополнительно обрезал до нужной пиксельной ширины.

Ну, вот. Надеюсь, я ответил примерно на вопрос про то, как можно фоткать. О том, как нужно фоткать я пока не знаю. Всё экспериментально.

Роман, с твоего позволения для фотографирования меню буду обращаться к тебе !

Буду помогать как смогу. Не могу обещать что буду резким как понос (т.к. процент гемора в совокупе довольно велик), но делать буду.

Я вот нафотал что-то, а дальше фоткать просто боюсь из-за того, что уже то что есть надо как-то систематизировать и разместить в неком WORD-е или в HTML-е…
Не могу понять - как это лучше сделать чтобы изменения и дополнения можно было живо и внятно вносить и при этом не запутаться. Т.е. я про то, что я таким ни разу не занимался, и когда ты и я будем вклинивать изменения в эту доку - то надо как-то определиться что мы делаем и как структурируем. Пунктов меню - как тараканов в бане… запутаемся нафиг…
У кого есть опыт такого документирования ? Как хотябы именовать жипеги… ?!

ДА уж… прочитал как ты делал эти фотки… “звезда в шоке”… 😃 я обычной мыльницей с рук фотографировал 😃))

по доке… - думаю я начну писать доку (составлю какой то каркас), потом будем все описывать по структуре меню… и в дальнейшем как и в первой версии кодера и доки к нему - сделаем несколько примеров настроек “под ключ”

Чтобы не потонуть в фото-материале, я наверное возьму сначала один какой-то “раздел” меню и профоткаю его вглубь. Опишем, потом сделаем ещё шаг, и так далее. А то, трудно будет если сначала родить весь фото-материал, а потом там рыться в нём как в помойке. Я ещё начал как-то не с самого начала, и уже вижу что выверт какой-то получается неприятный. Счас сгоняю в гости к токарю, а потом успею пофоткать ещё. За выходные, думаю переварить побольше.

Меня клонит на интерактивные (кликабельные) описания. В word-е кажется это всё делается. Удобно, когда описание становится длинным и нудным. Блин, я ещё не видел описание от первой версии. Надо поискать его и зачитать обязательно. Я то я как-то с хвоста к кобыле подхожу (а веть и лягнуть может) 😦

Есть ещё вот это. Может приглянется на первую страницу мануала ?.. Позже, сделаю ещё что-нить из области “фото главного виновника”.

Разкурочил аппу и активно работаю над подсветкой.
Непростой вопрос однако. Никогда не делал подобного, но что-то хорошее обязано получиться. Можно будет, я думаю, переснять все в более добротном виде. Если всё будет плохо - отрубить подсветку всегда можно.

Фото железа посветки выложи, то есть как приделал диоды к экрану изнутри.

Фото железа посветки выложи.

Сделаю тему в разделе самодельщиков. Но врят-ли я рожу что-то уникальное. Уже имеются материалы: Вариант_1, Вариант_2 и Вариант_3. Я дома, без ЧПУ смог попробовать повторить вариант_1. Сверление удалось, но появились паразитные яркостные пятнышки на экране. Это меня не устроило. Я положил примерно один выходной на эту плаху. 😦 Счас смотрю все ссылки, что я тут привёл - я рожу вариант_4 это точно. Думаю, что идеала я не буду добиваться (лёгкий градиент буду терпеть), но и пятен от разбегания света в разные стороны я не буду допускать.

Уже есть наработки (всё профотографировано) по модернизации кнопок этой чудесной аппаратуры. Просто, уже нет пути обратно: я и многие другие люди, уже развращены мягеньким тактовым “щелчком” кнопочек на сотовых телефонах. А тут - надо тестировать прошивки ❗ Ахтунг ! Нужно постоянно всё менять, сносить, набивать… Я просто в ауте от штатных кнопок. Они так щёлкают, нет, - клацают с неким ударом… что у меня всё опускается. Хочу получать удовольствие а не терпеть.

Прошу прощения за лёгкий оффтоп, но отчасти, это связано и с прошивкой и документированием самой прошивки.

Виталий! Включение подсветки будет происходить так же на 17-й ноге единица? Просьба - если есть свободный битик в епроме, давай введем в меню общих настроек устройства пункт подсветки: автовыкл.=да/нет, чтоб можно было работать с постоянно горящей подсветкой. Это можно к контрастности присовокупить…

да, подсветка будет на той же ноге… - не могу же я кинуть всех кто делал на 17ю ногу в первом кодере 😃))
на счет настройки подсветки наверное сделаю более менее полноценное управление подсветкой - вкл\выкл, время подсветки…

Виталий! А сейчас для тестирования надо принудительно перепаяться на вкл подсветки, или уже работает подсветка от V1? (тестирование происходит, как обычно, ночью:)).

Сегодня закончил работу по подсветке дисплея Турниги. сразу оговорюсь, идея не моя, подсмотрел на РЦД, мое только техническое исполнение.
Рассеиватель подсветки вырезал из рассеивателя портативного проигрывателя DVD, он оклеен белой пленкой, которую оставил. Торцы, которые при резке остались без пленки заклеил белой пленкой Оракал. Вдоль одной длинной стороны (на ней пленки нет) приклеил супермоментом шесть белых светодиов, светодиоды отпаял от световой ленты, которую ранее выписывал с ХС. Светодиоды соединил по два последовательно и затем три цепочки параллельно. У меня питание аппы от 2SLiPo, если аппа питается от 3SLiPo, то соединять последовательно по три светодиода. Запитал через общий резистор, хотя правильнее каждую цепочку питать через свой резистор. Микропорку, которая прижимает дисплей к корпусу, отклеил от платы и разрезал по толщине, тоесть уменьшил на толщину рассеивателя.
Замерил поточнее потребление аппы, Без подсветки потребляет 120 мА, с включенной подсветкой, при изменении U от 7.0 В до 8,4 В, ток меняется от132 мА до 143 мА
Ну и несколько фото в процессе изготовления и что получилось.

Вложения:

6.jpg [ 45 Кб | Просмотров: 148 ]

5.jpg [ 50.83 Кб | Просмотров: 148 ]

4.jpg [ 42.89 Кб | Просмотров: 148 ]

3.jpg [ 18.34 Кб | Просмотров: 148 ]

2.jpg [ 47.24 Кб | Просмотров: 148 ]

1.jpg [ 43.07 Кб | Просмотров: 148 ]

Залил прошиву, горит главное меню, движения по кнопкам нет, даже при 60 сек удержании… Лил только флэш после стирания чипа… После влил старый епром - нет улучшения… как надо разбудить монстра? (кстати, единица на 17-й ноге уже присутствует!)

Не получается пока фото вставить, если не получится и кому интересно, можно посмотреть на сайте rc70.ru, в разделе “электрика и электроника”-“аппа Turnigy 9X” стр.13.

Замерил поточнее потребление аппы, Без подсветки потребляет 120 мА, с включенной подсветкой, при изменении U от 7.0 В до 8,4 В, ток меняется от132 мА до 143 мА

Вот тут не понятно… при каком таки напряжении (с которым сравнивать) происходило измерение тока “Без подсветки”? Для качественного свечения диоды потребуют от 15 до 20 мА (а то и больше), три ветки = 45 - 60 мА, есть ли такой прирост?

Вадим, без подсветки, ток потребления аппаратурой (120 мА) не изменяется при изменении U от 7.0 В до 8,4 В. А то что получилось небольшое увеличение тока, возможно из-за большого номинала резистора, если его уменьшить, то потребление и яркость увеличатся, но меня устроила вполне получившаяся яркость. Измерение тока производил, включенным последовательно прибором (цешкой), а запитывал аппу от регулируемого блока питания.

Начинаю понимать… питали диоды от стабильного 5V? Тогда похоже… при повышении напряжения ток не менялся, но общая мощность возрастала (V*A), разница выделялась на резисторе… Но это и не важно уже… токовый прирост я обозначил выше, и вообще это оффтоп…

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

Повторяюсь - (для Виталия) Залил прошиву, горит главное меню, движения по кнопкам нет, даже при 60 сек удержании… Лил только флэш после стирания чипа (и для фото и до того)… После влил старый епром - нет улучшения… как надо разбудить монстра? (кстати, единица на 17-й ноге уже присутствует!)

Виталий, матрица для цифр 6х4 ? Девятку и шестерку я бы переделал. Просвет 2х2 и хвостик уменьшить.
А какую версию тестить? Vcoder1 уже полностью рабочий?

Сделаю тему в разделе самодельщиков. Но врят-ли я рожу что-то уникальное. Уже имеются материалы: Вариант_1, Вариант_2 и Вариант_3. Я дома, без ЧПУ смог попробовать повторить вариант_1. Сверление удалось, но появились паразитные яркостные пятнышки на экране. Это меня не устроило. Я положил примерно один выходной на эту плаху. 😦 Счас смотрю все ссылки, что я тут привёл - я рожу вариант_4 это точно. Думаю, что идеала я не буду добиваться (лёгкий градиент буду терпеть), но и пятен от разбегания света в разные стороны я не буду допускать.

ответил у себя в блоге как и чего по подсветке

Так, опять в технический оффтоп поднырнули… Давайте не вставлять сюда описания технических решений.
Ссылки… Ссылки… Ссылки… и короткие ответы. Сделал тему под подсветку. Кажется, про подсветку, как раз тот пример, когда из форума приходится делать некую отжимку в поисках полезной информации. Всё как-то распределено так, что с “пинцетом” приходится работать.

Виталий! А сейчас для тестирования надо принудительно перепаяться на вкл подсветки, или уже работает подсветка от V1? (тестирование происходит, как обычно, ночью:)).

Функционала подсветки еще нет… так что пока нечего смотреть

Залил прошиву, горит главное меню, движения по кнопкам нет, даже при 60 сек удержании… Лил только флэш после стирания чипа… После влил старый епром - нет улучшения… как надо разбудить монстра? (кстати, единица на 17-й ноге уже присутствует!)

Гм… странное поведение… кнопки должны работать…
фюзы точно не трогали ?
функционала подсветки пока нет !! так что ее пробовать бестолку

Виталий, матрица для цифр 6х4 ? Девятку и шестерку я бы переделал. Просвет 2х2 и хвостик уменьшить.
А какую версию тестить? Vcoder1 уже полностью рабочий?

Матрица символов 8х5…

VCoder рабочий… летабельный… вторая версия еще только как демонстрашка меню

Виталию - фьюзы на месте, щас влил V1 с епромом, - как так и было… удивляюсь… аппа Турнига 9х… не слышит кнопок, блин… надеюсь, кнопочные порты у всех апп одинаковые?

Пошагово - сохранил епром от V1 (работаю в кодэвижн с 910-м программатором, залита V1), стер чип, загрузил флэш (vcm.hex-файл), залил загруженный флэш - появился главное меню - движения нет, и после ресета тоже… Вливаю обратно V1…

Матрица 8х5 без пробелов даст 7х4. Минимально допустимое, чтобы не сливалось 7х5 плюс по пикселю на разделитель. Для меня уже мелко. Но 9 и 6 все равно надо бы переделать.
В каком модуле у вас обработка дребезга контактов. У меня что-то совсем нехорошо отрабатывает, то надо держать, потом перескакивает через два. Не пойму в чем дело. Стрелка вниз в родной была с небольшими проблемами, но не до такой степени. Когда по ехiт возвращаешься тоже двойное срабатывание иногда.

Георгий! Выложи плиз свой hex… мож, я не то лью…

Георгий! Выложи плиз свой hex… мож, я не то лью…

ЭЭЭ… как бы никакой флеш заливать для VCM.hex не нужно !!
Флеш от VCoder не совместим с VCM !!

просто залейте последнюю версию VCM и все !
последняя версия вот ->vcm.hex

Матрица 8х5 без пробелов даст 7х4. Минимально допустимое, чтобы не сливалось 7х5 плюс по пикселю на разделитель. Для меня уже мелко. Но 9 и 6 все равно надо бы переделать.
В каком модуле у вас обработка дребезга контактов. У меня что-то совсем нехорошо отрабатывает, то надо держать, потом перескакивает через два. Не пойму в чем дело. Стрелка вниз в родной была с небольшими проблемами, но не до такой степени. Когда по ехiт возвращаешься тоже двойное срабатывание иногда.

Я подготовлю файл шрифта… и выложу еще программу для его редактирования… - так что поупражняетесь по желанию со шрифтами… этот я рисовал вместе с drucsel… мне у этого шрифта и девятка не очень нравиться… 😃

по поводу дребезга - гм… вроде модуль более продвинутый… в меню везде отрабатывает кнопку только после отпускания…
при редактировании параметров (или суб меню) - по удержанию…
а вот возврат по exit точно должен быть адекватный… - скажите пункты меню где происходит произвольный выход ! - возможно я где то пропустил… - везде вставляю спец функцию которая ждет удержание кнопки exit…

Вот ссылка на программу редактирования шрифтов и файл шрифтов LCD_Font.zip.html

1. проверьте своим антивирусом (претензий на вирусы в exe не принимаю !)
2. распакуйте куда нить
3. запускайте екзешник
4. в диалоге отвечаете “CAncel”, потом Файл - Открыть и выбираете второй файлик (не забудьте в диалоге открытия файла поставить фильтр all files)
5. потом выбираем символ в правой половине окна и редактируем в левом…

по формату 6 на 4 !!! верхняя и нижняя строки только для символов где нужно ! и начиная с 5того столбца пусто ! для горизонтального интервала… ну в принципе для некоторых символов можно занимать 5ый столбец… - но не злоупотребляйте !

6. после редактирования делаете Файл - Save и получаете файл шрифта

Я вначале 90-х сотню, а может и больше, принтеров русифицировал, поэтому со шрифтами работал. Русский шрифт имеет десяток буков типа м, ш, щ, ф, ы, ж, ю… которые в 4 клетки просто не рисуются, а в 5 сливаются. Стандарт 9х6, минимум 7х5 плюс пиксель. Чем вызван такой мелкий шрифт? Стартовое меню явно перегружено. Вообще-то по меню отдельный разговор, более важный.

если делать шире - то всего 20 символов умещается на экран по горизонтали … а этого мало… тут 25 символов и то в обрез !!
таков вот он русский язык 😦

сливаются не многие буквы… в принципе была мысль сделать шрифт переменной длинны - может быть стоит действительно этим заморочиться…

по структуре меню - готов обсуждать - давайте ваши варианты

кстати в прошивке если заметили используются только большие буквы !! маленькие у меня не получились в шрифте… 😦

и еще одно “кстати” нарисуйте кто нить шрифт переменной длинны! я попробую под него переписать модуль печати!

ОООО!

ЭЭЭ… как бы никакой флеш заливать для VCM.hex не нужно !!
Флеш от VCoder не совместим с VCM !!

Не в обиду - Сэр - Прошу не держать меня за идиота от Чехова! Моими прошивками пользуются пол-страны для добычи нефти-газа в бюджет… Последняя публикация hex. файла работает аналогично предыдущей… Есть ли пользователи,влившие прошивку со мной вместе?

Блин… блин… монитор отказал… пришлось отобрать у сына… блин… блин… оказалось - контакт в питании… Неужели даже в розетку надо брызгать контактолом: таки ок! Прошива все одно не работает!

Виталий! Кинь мне в личку свой номер тлф, всенародно обязуюсь перечислить туда 500р. за твой труд (по крайней мере за V1).

Блин… блин… не голосуйте за Единую Россию… блин… Домодедово… блин…

не голосуйте за Единую Россию

Это и так давно понятно…😆

Автору агромное спасибо за прошивку V1, почитал монуал все понятно в отличии от стандартной. Аппа тока в пути надо будет програматор прикупить и залить сразу норм прошивку. Жду не дождусь рускоязычной V2. Кстати энтузиазм автора до сих пор поражает. На бесплатной основе делать такие замичательные весчи)).
Может быть вы скинете сюда ваш номер wmr кошелька, да благодарные люди вам спонсорскую помошь будут давать. Я 2-й в их числе после Вадима Камоцкий.

ОООО!
Не в обиду - Сэр - Прошу не держать меня за идиота от Чехова! Моими прошивками пользуются пол-страны для добычи нефти-газа в бюджет… Последняя публикация hex. файла работает аналогично предыдущей… Есть ли пользователи,влившие прошивку со мной вместе?

гм… ты меня убиваешь наповал… 😦
что за программатор, программа для заливки ?
странно…
если первая версия работает - то и вторая должна работать…

НАРОД!! залейте кто нить vcm.hex - у вас работает меню ?!!

p.s. у меня все в порядке…

Автору агромное спасибо за прошивку V1, почитал монуал все понятно в отличии от стандартной. Аппа тока в пути надо будет програматор прикупить и залить сразу норм прошивку. Жду не дождусь рускоязычной V2. Кстати энтузиазм автора до сих пор поражает. На бесплатной основе делать такие замичательные весчи)).
Может быть вы скинете сюда ваш номер wmr кошелька, да благодарные люди вам спонсорскую помошь будут давать. Я 2-й в их числе после Вадима Камоцкий.

у меня нет кошелька… для особо желающих могу сказать номер карты ВТБ24 (ее пополнять можно из любого отделения банка по номеру, правда еще паспорт с собой нужно брать)… могу пообещать что все полученные деньги на дальнейшую разработку и пойдут (задумок то еще много… тот же FrSky прикрутить в мыслях для полноценной телеметрии прямо на экране аппы)…

P.s. а вообще я пишу прошивки не за деньги, а просто потому что мне это занятие нравиться… сейчас правда у меня небольшой отпуск от кодевижна… чтото заморили меня последние менюхи 😃))

у меня нет кошелька… для особо желающих могу сказать номер карты ВТБ24

Сообщи, если не лень. Как раз со своей карты ВТБ кину. Будет на что прикупить ещё железа для экспериментов 😛.

Ремонт - это когда весь коридор завален стройматериалами и жена очень косо смотрит на компьютер. Поэтому пока мало чем помогу.
Переменные шрифты - хорошая идея. Посмотреть можно в Paint, выберите шрифт Microsoft Sans Serif и Microsoft Serif, размер 7. Набрать в масштабе Обычный, потом увеличить. Все корявости сразу видны и их можно исправить в редакторе.
Я хоть и рисую менюшки на тачскринах последние десять лет, но помочь тоже могу мало. Опыта нет. Надо взять для образца хорошую аппу. Нельзя перегружать экраны в рабочем режиме. Только самое необходимое. Логика тоже должна быть общая и интуитивно понятная. Почему числа изменяются Up и Down, а не + и - непонятно.
Куда делся Switch error? Хотелось бы подтверждение модели при включении. Есть печальный опыт.
Крайние пиксели практически не видно, может оставить пустыми?

А у нас железо одинаковое?
Я загрузил оттранслированный исходник и кнопки у меня явно срабатывают не по отпусканию, а по нажатию. Если нажать и держать, будет скакание по меню.
Может текущие последние прошивки выложить где-нибудь на видном месте?

гм… в vcm.hex навигация по меню только при нажатии и отпускании кнопки !!! не может быть скакание по меню при удержании !! прошу проверьте еще раз !!
скакание по меню было в первом кодере (VCoder)…

Ремонт - это когда весь коридор завален стройматериалами и жена очень косо смотрит на компьютер. Поэтому пока мало чем помогу.

Сочувствую… я это проходил 3 года назад 😃

Переменные шрифты - хорошая идея. Посмотреть можно в Paint, выберите шрифт Microsoft Sans Serif и Microsoft Serif, размер 7. Набрать в масштабе Обычный, потом увеличить. Все корявости сразу видны и их можно исправить в редакторе.

ну пока просто не хочу тратить на это время… в настоящее время есть куча вещей которые нужно написать (переписать), придумать, проверить, отладить…
мне проще отложить меню и шрифты на потом… тем более что текст это всего лишь текст… - редактируется в любой момент…

Логика тоже должна быть общая и интуитивно понятная. Почему числа изменяются Up и Down, а не + и - непонятно.
Куда делся Switch error? Хотелось бы подтверждение модели при включении.

С логикой в железе тяжко… я вот никак не могу привыкнуть что плюс слева а минус справа !! ну блин убейте меня, но в школе учили что влево шкала уменьшает значение а в право - увеличивает !!! в первом кодере сделал как на кнопках (увеличение кнопкой + (слева), уменьшение кнопкой - (справа)) - так потом сам не мог пользоваться !! у меня влево это минус, а вправо это плюс !!
кстати есть некоторые меню в которых изменение значения происходит нажатием кнопок +\-… - обычно это субменю…
пока пусть будет как есть в дальнейшем если останеться места в программной памяти сделаю изменение через внешний simple-edit (это тот через который происходит изменение параметров кнопок, экрана, включение\выключение звука и т.д.) - просто для него приходиться расходовать доп. память на подсказки, а ее я начал экономить… останеться - перекину редактирование параметров на него (тем более что это не сильно усложняет код - у меня такие вещи реализуются через стек вызовов (call\ret) - так что все по взрослому 😃))

по поводу switch error - гм… а меня наоборот бесил… - подумаю над этим… может быть сделаю описатель первоначальных положений органов управления для модели по которым будет проверяться аппа после загрузки модели… -просто это дополнительный расход очень маленького ЕЕПРОМа который итак расходоваться будет раза в 2 больше чем в первом кодере…

Крайние пиксели практически не видно, может оставить пустыми?

крайние слева или справа ?

а меня наоборот бесил…

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

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

Но Up то сверху!!! Пусть + будет слева, при подъеме руля сам летит вниз, а вверх ногами наоборот. Привыкнем.

кстати есть некоторые меню в которых изменение значения происходит нажатием кнопок +\-.

Я об этом и говорю. Это недопустимо. Либо так, либо так.

• и - можно использовать и для хождения по столбцам меню, т.е. как стрелки, и для изменения значений. Это нормально и интуитивно понятно. Значения, после выделения, можно менять всеми 4-мя кнопками.
  Про пиксели погорячился, это от бокового освещения.

залейте кто нить vcm.hex - у вас работает меню ?!

Залил. Работает.
У кнопки Exit (по крайней мере) слишком длинное время срабатывания. Т.е. постоянно приходится нажимать ее два раза.
Замыкание оно и в Африке замыкание. Достаточно его однократного обнаружения. Временем отпускания ликвидируем дребезг (у меня обычно 0.2 -0.3 сек, подбираю опытным путем). Т.е. лучше пусть не сработают два быстрых нажатия подряд (редко это надо), чем не сработает одно короткое нажатие.
Наверно, еще привычка влияет. Сейчас уже лучше работает.
Чем различаются “сохранение модели” от “записи модели”? Вроде по-русски, а интуитивно непонятно. (Инструкцию не читаю специально, должно быть понятно без нее)

Всё, я технически полностью готов к фотографированию менюх. Завтра начну долбить…
Всё удалось на славу.

Залил. Работает.
У кнопки Exit (по крайней мере) слишком длинное время срабатывания. Т.е. постоянно приходится нажимать ее два раза.

Кнопка EXIT отдельно не обрабатывается… это конструктивный глюк… у меня плохо нажимается на аппе кнопка MENU (причем на штатной прошивке тоже - иногда даже не могу войти в меню ! не хватает нажатия), с EXIT все впорядке…

Замыкание оно и в Африке замыкание. Достаточно его однократного обнаружения. Временем отпускания ликвидируем дребезг (у меня обычно 0.2 -0.3 сек, подбираю опытным путем). Т.е. лучше пусть не сработают два быстрых нажатия подряд (редко это надо), чем не сработает одно короткое нажатие.

Этот параметр регулируется пользователем через меню “НАСТРОЙКА ПЕРЕДАТЧИКА” - “НАВИГАЦИЯ ПО МЕНЮ” - “ЗАДЕРЖКА НАВИГАЦИИ”
ставьте минимальные значения - это и будет время для регистрации нажатия…

Наверно, еще привычка влияет. Сейчас уже лучше работает.

😃

Чем различаются “сохранение модели” от “записи модели”? Вроде по-русски, а интуитивно непонятно. (Инструкцию не читаю специально, должно быть понятно без нее)

“СОХРАНЕНИЕ МОДЕЛИ” - это обновление информации о модели на диске - то есть поднастроили и сохранили изменения… запроса нового места для сохранения модели не происходит.
“ЗАПИСЬ МОДЕЛИ” - это запись модели на диск с запросом нового места (например запись модели в другое место чтобы иметь возможность поэксперементировать с настройками, но и чтобы не потерять уже настроенную модель)

Всё, я технически полностью готов к фотографированию менюх. Завтра начну долбить…
Всё удалось на славу.

Да, действительно классно получилось !! очень ровная подсветка… посмотрел и захотел себе такую же ! 😃))

Кстати, а сколько потребляет аппа с передающим модулем и сколько отдельно модуль подсветки ?
а то может не заморачиваться с отключением подсветки а просто включить его на постоянную ? (ну как минимум сделать такой вариант выбора)

Никогда бы не догадался. 😃
Как-то привык к Новая, Сохранить, Копировать. В крайнем случае Сохранить Как, хотя это уже излишек.
Сейчас смотрю прошивку ER9X.
Кажется новые прошивки становятся самоцелью. 😃

Да, действительно классно получилось !! очень ровная подсветка… посмотрел и захотел себе такую же ! 😃))

Придётся разбить любимый IPhone, или ограбить ближайший ремонт сотиков… 😃

Кстати, а сколько потребляет аппа с передающим модулем и сколько отдельно модуль подсветки ?

Чуть выше писали:

Замерил поточнее потребление аппы, Без подсветки потребляет 120 мА, с включенной подсветкой, при изменении U от 7.0 В до 8,4 В, ток меняется от132 мА до 143 мА

Про свой ток подсветки - я писал в соей ветке. У всех - будет по-разному.

…а то может не заморачиваться с отключением подсветки а просто включить его на постоянную ? (ну как минимум сделать такой вариант выбора)

Вариант выбора такой нужен. Это 100%.
Я планирую подсветку сделать независимой пока. А то фоткать я устану. Только фокус взял на фотике - херак, а она гаснет. Ну что за дерьмо ?!!!

Я планирую подсветку сделать независимой пока. А то фоткать я устану. Только фокус взял на фотике - херак, а она гаснет. Ну что за дерьмо ?!!!

На тумблер вешать будете?

На тумблер вешать будете?

Ответил в теме, чтобы не плодить тут оффтоп.

Скачал исходник для ER9X. Файлы имеют расширение .cpp и транслируются в пакетном режиме WINARV.
Есть ли возможность транслировать их codevisionov? Чем их просматривать и редактировать посоветуете?

возможность всегда есть… просто править придется много скорее всего…
синтаксис немного у кодевижна отличается от winavr…

Виталий, где у вас в новой прошивке фонты, сколько их и какой формат? В старой шрифты просматриваются легко, а в новой я их не вижу, а с битами играть времени нет.

гм… что значит где они ? шрифт это по 5 байт на символ… я как то особо не задумывался куда их компилятор засовывает…
выше были ссылки на файл шрифтов и программу для их редактирования… если есть желание править- используйте программу - я потом вставлю шрифт в прошивку

Нужда в перекодировке bin hex и обратно не прошла? Софт к моему программатору делает это. В открытом доступе.
www.argussoft.ru/vendors_list/argussoft/…/asisp
или на сайте разработчика www.as-kit.ru
Эти действия софт делает без платы. Может кто надумает поменять свои “пять проводочков”.

“СОХРАНЕНИЕ МОДЕЛИ” - это обновление информации о модели на диске - то есть поднастроили и сохранили изменения… запроса нового места для сохранения модели не происходит.
“ЗАПИСЬ МОДЕЛИ” - это запись модели на диск с запросом нового места (например запись модели в другое место чтобы иметь возможность поэксперементировать с настройками, но и чтобы не потерять уже настроенную модель)

А не удобнее будет:
“РЕДАКТИРОВАТЬ МОДЕЛЬ” - т.е. обновить/исправить существующую информацию по настройкам модели, и “СОЗДАТЬ МОДЕЛЬ” - т.е. создань новую ячейку с настройками модели (заново или/и на основе имеемой)

гм. редактировать в меню сохранения данных ? помоему будет еще большая путаница…

гм. редактировать в меню сохранения данных ? помоему будет еще большая путаница…

Ну… СОХРАНЕНИЕ и ЗАПИСЬ как-то, действительно, не совсем очевидно.
Хотя - дело привычки. Наверное такая “неочевидность” идет от привычки пользоваться ПО на РС. Там бы это действительно звучало бы как СОХРАНИТЬ, и СОХРАНИТЬ КАК.

МОжет тогда обозвать - “сохранить” и “сохранить как” ?

Так лучше… Тем более как то привычно даже выглядит

Поддерживаю

Очередная версия для тестов vcm.hex.html

При сохранении модели назвал пункты меню: СОХРАНИТЬ и СОХРАНИТЬ КАК…

Что скажите про новый редактор кривых ?
не дописаны пока только экспоненты (у меня нет матрицы экспоненты, как найду допишу)
Реализованы:

• выбор количества точек кривой: 3,5,7,9
• выбор кривой из шаблонов
• настройка кривой вручную
  Будет дописано - наложение экспоненты

По шаблонам кривых:
кому какие кривые нужны ?
сейчас самое время сказать мне об этом… а лучше описать в следующем формате
Так что давайте коллегиально решайте какие кривые нужны… всего возможно по 8 кривых на каждый вид (3,5,7,9 точек)
числовые значения соответственно в процентах… в целых числах !
диапазон как и в vcoder от -100% до +100%
как выглядят некоторые шаблоны можно посмотреть в прошивке ссылку на которую я дал вначале сообщения (смотрите в трехточечных кривых)

В общем жду массива в формате:

flash const signed char preset_curves[4][8][9]={
 { // кривые из трех точек
   //        |            ------------------------------
   { -100,   0,   0,   0,   0,   0,   0,   0,   0 },
//     1      2     3    +--+--+---+----+--+----- не используется на 3х точках
//              |
//              +----- центр для трех точечной кривой
   {    0,   0, 100,   0,   0,   0,   0,   0,   0 },
   {  100,   0,-100,   0,   0,   0,   0,   0,   0 },
   {  100,   0,   0,   0,   0,   0,   0,   0,   0 },
   {    0,   0,-100,   0,   0,   0,   0,   0,   0 },
   {  100,   0, 100,   0,   0,   0,   0,   0,   0 },
   { -100,   0,-100,   0,   0,   0,   0,   0,   0 },
   {    0,   0,   0,   0,   0,   0,   0,   0,   0 }
 },
 { // кривые из 5 точек
   //             |           --------------------
   { -100,   0,   0,   0, 100,   0,   0,   0,   0 },
   {  100,   0,   0,   0,-100,   0,   0,   0,   0 },
   {    0,   0,   0,   0,   0,   0,   0,   0,   0 },
   {    0,   0,   0,   0,   0,   0,   0,   0,   0 },
   {    0,   0,   0,   0,   0,   0,   0,   0,   0 },
   {    0,   0,   0,   0,   0,   0,   0,   0,   0 },
   {    0,   0,   0,   0,   0,   0,   0,   0,   0 },
   {    0,   0,   0,   0,   0,   0,   0,   0,   0 }
 },
 { // кривые из 7 точек
   //                  |                 ----------
   {    0,   0,   0,   0,   0,   0,   0,   0,   0 },
   {    0,   0,   0,   0,   0,   0,   0,   0,   0 },
   {    0,   0,   0,   0,   0,   0,   0,   0,   0 },
   {    0,   0,   0,   0,   0,   0,   0,   0,   0 },
   {    0,   0,   0,   0,   0,   0,   0,   0,   0 },
   {    0,   0,   0,   0,   0,   0,   0,   0,   0 },
   {    0,   0,   0,   0,   0,   0,   0,   0,   0 },
   {    0,   0,   0,   0,   0,   0,   0,   0,   0 }
 },
 { // кривые из 9 точек
   //                       |
   {    0,   0,   0,   0,   0,   0,   0,   0,   0 },
   {    0,   0,   0,   0,   0,   0,   0,   0,   0 },
   {    0,   0,   0,   0,   0,   0,   0,   0,   0 },
   {    0,   0,   0,   0,   0,   0,   0,   0,   0 },
   {    0,   0,   0,   0,   0,   0,   0,   0,   0 },
   {    0,   0,   0,   0,   0,   0,   0,   0,   0 },
   {    0,   0,   0,   0,   0,   0,   0,   0,   0 },
   {    0,   0,   0,   0,   0,   0,   0,   0,   0 }
 }
};

Ищу матрицу экспоненты по максимальному числу точек…
в виде описания координат точек… - по этому можно здесь, можно в личку

p.s. начал писать редактор микшеров… но пока чтото не вытанцовывается он у меня по простому… а то что есть не очень нравиться…

(задумок то еще много… тот же FrSky прикрутить в мыслях для полноценной телеметрии прямо на экране аппы)… 😃))

Ну О-Очень интересно!!!
Нужно бросить клич среди юзателей FrSky и читателей/писателей в профильной теме rcopen.com/forum/f4/topic186091/705
Думаю, обладатели турниг-флайскаев-имаксов и пользующие телеметрийные комплекты FrSky поклонятся Вам в ноги и может деньжат подкинут на тесты железа в указанной связке.
Ведь отказ от доп монитора это ж как минимум экономия на его стоимости ~~ 20$

посмотрим… пока кидать рано… прошивка еще ппм не генерит 😃 соответственно пока телеметрия и не нужна (самолет управляемый ее - не полетит 😃))
Сначала сделаю генерацию ппм (В принципе из подготовительных мероприятий доделать редактор микшеров, ну и собрать модуль чтения\сохранения моделей на vdisk), потом по плану стоит захват ппм с тренерского разъема (давно уже обещал… в принципе и алгоритм себе накидал, так что только вживить и протестировать), а вот потом уже телеметрию бум вживлять (Если места в 64-ой меге хватит… а то уже сейчас 55% занимает прошивка…)

(Если места в 64-ой меге хватит… а то уже сейчас 55% занимает прошивка…)

Сорри если чего не дочитал в Вашем дневнике, но ИМХО в памяти пульта достаточно иметь 3-8 моделей, а остальные хранить на компе, все равно в поле редко кто выезжает с 3 и более моделями под один пульт. За счет этого может найдете место для связки Фрскаевской телеметрии с сабжем. Если чё сморозил - не бейте.

совершенно согласен по поводу экономии места за счет разумного количества файлов моделей . У меня вопрос по поводу мультиплексирования, что это такое?, в документации к действующей прошивке 0.99b ,про это мало информации . Насколько я понял в один канал можно вложить еще какуюто команду , расширив 8 каналов на большее количество, было сказано что нужен мультиплексатор ,что это ,и как он работает? Спасибо.

… расширив 8 каналов на большее количество…

Это оно и есть. По одному каналу можно передавать несколько.

было сказано что нужен мультиплексатор

дешифратор… железяка, которая с одного принятого канала приемника раздает сигнал на несколько исполнительных механизмов…
Может кто-нибудь имеет опыт и время чтоб реализовать аппаратную часть?

это случайно не оно? www.hobbycity.com/hobbycity/…/M_Fswitch.jpg

Сорри если чего не дочитал в Вашем дневнике, но ИМХО в памяти пульта достаточно иметь 3-8 моделей, а остальные хранить на компе, все равно в поле редко кто выезжает с 3 и более моделями под один пульт. За счет этого может найдете место для связки Фрскаевской телеметрии с сабжем. Если чё сморозил - не бейте.

А я не о памяти для моделей говорил…
Моделей планирую штук 6-8 уместить…
Речь идет о программной памяти… ее расходую очень быстро… поэтому приходиться возвращаться и переписывать код с целью оптимизации по размеру

это случайно не оно? www.hobbycity.com/hobbycity/…/M_Fswitch.jpg

Нужно по описанию смотреть…
возможно что это железка похожего функционала - но работать с фильтром MULTI вряд ли будет…

В кратце- фильтр MULTI делает следующее:
передает стартовый маркер - это длительность канального импульса около 800 мкс (могу позже посмотреть точнее),
следом, в четырех следующих пачках передаются последовательно данные по 4м каналам
каждый мультиплексированный канал будет обновляться с частотой 50\(4 канала + 1 маркер)= 10 гц…
конечно для управления полетом использовать его нельзя… а вот для открытия всяких бомболюков, мигания лампочками и прочего функционала (например управления камерой для FPV) - пойдет за глаза…

По количеству каналов можно получить разные варианты:
7 каналов-RT + 1 канал-MULTI = 7+4= 11 каналов с 8ми канального приемника
6 каналов-RT + 2 канала-MULTU = 6+2*4= 14 каналов с 8ми канального приемника
естественно можно будет использовать и 6ти канальные приемники:
5 каналов-RT + 1 канал-MULTI = 5+4= 9 каналов с 6ти канального приемника
4канала-RT + 2 канала-MULTU = 4+2*4= 12 каналов с 6ти канального приемника
и даже трех и четырехканальные 😃 правда для самолета наверное RT каналов будет уже маловато… хотя иногда возможно на канале Тяги использовать MULTI канал…

Соответственно демультиплексор это устройство собранное на микроконтроллере (pic, avr) - которое берет данные с одного канала, и дешифрует их на 4…
алгоритм есть выше.
если кто попробует сделать его - буду очень рад, у меня сейчас к сожалению на это времени нет (хотя задача не такая уж и сложная)…

либо у меня есть предложение - если кто нить соберет мне железку по схеме (я могу ее попробовать нарисовать) - и вышлет (готов оплатить железку и доставку) - то могу попробовать начать писать прошивку демультиплексора…
сам к сожалению уже давно ничего не паяю кроме проводков для программирования к аппе…

Может, я чего не понял… 4 мульти-канала умещаются по времени в один канал RT (2мсек)? Если нет, то общее время передачи пачки всех каналов увеличивается и выходит за 20 мсек?

Виталий, по поводу кривых - это конечно экспонента “+” и " -", V образная.

Может, я чего не понял… 4 мульти-канала умещаются по времени в один канал RT (2мсек)? Если нет, то общее время передачи пачки всех каналов увеличивается и выходит за 20 мсек?

да, непонял 😃

четыре канала передаются в 5-и пачках !!!
1 пачка - все каналы как положено, мульти канал 800 мкс
2 пачка - все каналы как положено, мульти канал - значение первого мультиплексируемого канала
3 пачка - все каналы как положено, мульти канал - значение второго мультиплексируемого канала
4 пачка - все каналы как положено, мульти канал - значение третьего мультиплексируемого канала
5 пачка - все каналы как положено, мульти канал - значение четвертого мультиплексируемого канала

То есть общая длина пакета будет стандартная… передается всегда в пачке 8 каналов (для 8 канального приемника)… просто в например в последнем, 8ом канале поочереди будет появляться маркер в 800 мкс, и потом каналы…
потому и обновление по MULTI каналам происходит с частотой не 50 а 10 гц…

Виталий, по поводу кривых - это конечно экспонента “+” и " -", V образная.

такой ответ мне не нужен…
выше есть массивы для описания кривых - вот в его формате и нужно…

V-образные кривые, образованные экспонентами при k=1, 2, 3, 4 (Виталий знает, о чем речь), рогами вверх и вниз.
{ // кривые из 9 точек
// |
{ 100, 44, 15, 2, 0, 2, 15, 44, 100 },//k=1
{ 100, 47, 17, 4, 0, 4, 17, 47, 100 },//k=2
{ 100, 51, 21, 6, 0, 6, 21, 51, 100 },//k=3
{ 100, 58, 29, 10, 0, 10, 29, 58, 100 },//k=4
{ -100, -44, -15, -2, 0, -2, -15, -44,-100 },
{ -100, -47, -17, -4, 0, -4, -17, -47,-100 },
{ -100, -51, -21, -6, 0, -6, -21, -51,-100 },
{ -100, -58, -29, -10, 0, -10, -29, -58,-100 }
}

V-образные кривые, образованные экспонентами при k=-1, -2, -3, -4 , рогами вверх и вниз.
{ // кривые из 9 точек
// |
{ 100, 98, 86, 56, 0, 56, 86, 98, 100 },//k=-1
{ 100, 96, 83, 53, 0, 53, 83, 96, 100 },//k=-2
{ 100, 94, 79, 49, 0, 49, 79, 94, 100 },//k=-3
{ 100, 90, 71, 43, 0, 43, 71, 90, 100 },//k=-4
{ -100, -98, -86, -56, 0, -56, -86, -98,-100 },
{ -100, -96, -83, -53, 0, -53, -83, -96,-100 },
{ -100, -94, -79, -49, 0, -49, -79, -94,-100 },
{ -100, -90, -71, -43, 0, -43, -71, -90,-100 }
}

Подразумевается, что точки по горизонтали равно-отстоящие друг от друга.

Нет, все-таки собака где-то определенно зарыта…
Залил последний релиз vcm.hex, вижу “Главное меню”
ЧТЕНИЕ/ЗАПИСЬ МОДЕЛЕЙ
РЕДАКТИРОВАНИЕ МОДЕЛИ
НАСТРОЙКА ПЕРЕДАТЧИКА

но реакции на кнопки нету, ничем не могу заставить сдвинуться курсор с места или войти в фокусный (первый) пункт. Подсветка горит постоянно.
Точно ли для кнопок используются те же порты, что и в V1? Кто нибудь еще заливал V2 прошиву в Турнигу 9х?

Нет, все-таки собака где-то определенно зарыта…
Залил последний релиз vcm.hex, вижу “Главное меню”
ЧТЕНИЕ/ЗАПИСЬ МОДЕЛЕЙ
РЕДАКТИРОВАНИЕ МОДЕЛИ
НАСТРОЙКА ПЕРЕДАТЧИКА

но реакции на кнопки нету, ничем не могу заставить сдвинуться курсор с места или войти в фокусный (первый) пункт. Подсветка горит постоянно.
Точно ли для кнопок используются те же порты, что и в V1? Кто нибудь еще заливал V2 прошиву в Турнигу 9х?

Гм… странное поведение…
порты точно такие же у меня тестовая аппа - Турниги V2

может криво скачалась прошивка или залилась в аппу ?
еепром никакой не заливали ? (он не нужен)

Новая версия для тестов vcm.hex.html

Добавлен механизм экспонент в кривые…
теперь кривая экспоненты может быть одна от -100 до +100 %%,
или быть разбитой на две кривой от -100 до 0 и от 0 до +100%
каждый отрезок разбитой кривой может иметь положительную или отрицательную зависимость (индивидуально), и свое значение коэффициента влияния (такие прикольные горбики можно делать !)
при включении экспонент у пункта меню “ЭКСПОНЕНТА” появляется “+” (задана экспонента)

внутри меню:

ТИП [ 1-0-2, 2-0-4, 3-0-2, 1-0-4, ЕД.32, ЕД14 ] - типы кривой,
первые 4 типа - это сдвоенные кривые, два отрезка с влиянием экспоненты управляемые отдельно, в кодировке задано нахождение отрезков кривой по квадратам координат
1 2
3 4
соответственно 1-0-2 - это кривая левая часть которой находится в квадрате 1, потом идет в 0 (центр), потом идет в квадрат 2 - это вторая кривая
соответственно 3-0-4 - это кривая которая слева находится в квадрате 3, потом 0, и потом квадрат 4 - это вторая кривая…

для таких кривых задается положительное или отрицательное влияние каждой из кривых (левой и правой) в параметре:
ЗНАК [ +/+, +/-, -/+, -/- ] - cоответственно первый знак - для левой кривой, второй для правой

и далее идет два коэффициента кривых (левой и правой) - которые задают процент влияния экспоненты на кривую… обращаю внимание знак указывается в пункте ЗНАК !! поэтому коэффициенты всегда положительные !

Для кривых с типом ЕД.32 и ЕД.14 - это единая кривая с экспонентой ! соответственно через центр (0) - график не проходит ! - обычно такие кривые нужны для канала тяги

соответственно ЗНАК у такой кривой может быть только в 2х вариантах либо +/+ либо -/-…

так же коэффициент влияния экспоненты тоже только один…

далее, как всегда, нажатие на MENU - сохраняет график, нажатие EXIT - возврат без изменения кривой (останется та которая была до входа в редактор экспонент)
при изменении количества точек кривой (по умолчанию 9) - экспоненты отключаются…
так же полученный график экспоненты можно редактировать вручную - но при этом через меню экспоненты - график редактировать уже нельзя (так как это не экспонента - будет предложено создать график заново)

в общем попробуйте - очень интересный редактор получился… может быть вживить его в VCoder ?

p.s. прочитал сейчас описание - в реале редактор быстрее прочувствуете без мануала… по крайней мере понять нужно только как задает местонахождение графикой экспонент (это про 1-0-4 и т.д.), знаки, коэффициенты - интуитивны…

p.p.s. вместо того чтобы спать ночью - до 2х часов писал этот редактор… кстати использование памяти уже 60%… блин, нужно чтото срочно оптимизировать !

ооо!! чуть не забыл !! за экспоненты ОГРОМНОЕ СПАСИБО Вадиму Камоцкину (vadimka29), это он мне прислал небольшой модуль расчета экспоненты и пару скриншотов я лишь навернул на точки рассчитанные его модулем функционал редактирования !

может криво скачалась прошивка или залилась в аппу ?
еепром никакой не заливали ? (он не нужен)

Может и так… на сайте размер файла 115.13кб (новый), скачал - размер=117.893 кб, а какой размер на самом деле? После стирания чипа епром должен почиститься, но пробовал и старый вставлять - и в том и в другом случае результат одинаковый… Попробую еще IE скачать, может Мозилла чего-то тупит? Щас только обнаружил в свойствах файла - указано, типа, скачан с другого компа и ныне заблокирован, разблокировать? Что бы это значило? Размер разблокированного файла не изменяется…

помоему очень интересный редактор получился… может быть вживить его в VCoder ?

Конечно вживить! А то там нужную кривую - только руками, на глазок…

размер нового файла 117 893…
кстати мозила иногда действительно на скачивание с народа глючит (У меня при использовании внешней качалки… - поэтому качаю файлы только ее… такая фигня только на народе)

ну чтобы вживлять- сначала потестируйте, а то вдруг не понравится !

ОО! кстати, фюзы не меняли ??
такие глюки обычно бывают с неправильными фюзами !!!
проверьте !!

я давал картинку фюзов в соседней ветке дневника про программирование аппаратуры… либо еще картинку фюзов давайл Алексей в своей ветке про альтернативку Focus/MSV

Нет, фьюзы не трогал… Как были с родной прошивкой, так и остались. С картинкой сравнил - ОК. Конечный адрес в КодеВижн определяется 0х51DA (16-раз слов), что хорошо стреляется с последним символом в hex файле 0хA3B5 (0x51DA*2+1), т.е. декодируется правильно. Правда, в редакторе бинарника вижу коды младшим байтом вперед, в AVR такая адресация слов, видимо…
Епром заливал FF-ками… Сравнивал залитый флэш с файлом - ОК. Даже не знаю, что и думать… 😦
P.S. Виталий, нельзя ли выложить рабочий бинарный файл (в архиве)?

Залил последнюю. На кнопки реагирует. Главное меню всегда остается?

Главное меню всегда остается?

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

Вадим, а вы после прошивки отключаете программатор от аппы ?
возможно что ваш программатор удерживает линию и поэтому кнопки меню не работают…

p.s. у меня при подключенном программаторе иногда вообще аппа не показывает ничего… отключаю его - и все ОК…

Поверьте, всяко уж делал…
Друзья! Кто нибудь, пожалуйста, посмотрите осциллографом на работающей V2 время выхода из 0 в 1 на кнопке MENU, эта цепь выходит на разъем программатора на вывод SCK.
У меня в Турниге 9х на портах кнопок стоят RC подавители, где R=1к (102), С=0.1мкф, в результате время выхода из 0 в 1 (отпускание кнопки) составляет около 5мсек до 2V, до 4V выходит за 15мсек. Что-то у меня большие сомнения по поводу 1к, должно быть (сам бы так сделал) 100-200 ом.

А V1 у меня и льется и работает прекрасно!

блин… статистики мало… нужно чтобы народ по заливал VCM и ответил работает навигация по меню или нет…
тогда и будет понятно - проблема только твоего железа или в коде…

кстати скорее всего проект vcm будет свернут 😦
сейчас еще кое что отрабатываю и начинаю полностью рефакторить… мне вообще не нравиться интерфейс… а так как нравиться я не умещаюсь в 64-мегу…
сейчас усиленно читаю про асм для avr…

Ну вот тебе и на:( В вопросах написания программ я профан и понимаю, что Вам видней, наверно возможности меги64 и так на пределе.
НО. Виталий, если начнете новый проект прошивки, оч хотелось бы минимального вмешательства в железо сабжа!!! Ну не знаю… доп платы с доп атмегой128 что ли. Иначе новая прошивка (сколь ни была бы она привлекательной) в массы не пойдет.ИМХО. Ногами не пинайте.

поэтому и перейду наверное на ассемблер - это как раз и позволит остаться в том же железе !
а иначе уже нужно паять в аппу 128ю мегу… (если использовать текущий код написанный на СИ)

Фух!! перепугали насмерть. Удачи в священнодействе!😁

Ой, Виталий… окстись… запаришься ведь, не дойдя до ОС… а там еще математика, бесконечный ручной оверлей, стек, и прочее… отвлекаться нельзя ни на день (для полного контроля)… Хотя, по-большому - лучше асм-контроля не придумаешь! Переживаю за Ваше самочувствие… 😃

Ой, Виталий… окстись… запаришься ведь, не дойдя до ОС… а там еще математика, бесконечный ручной оверлей, стек, и прочее… отвлекаться нельзя ни на день (для полного контроля)… Хотя, по-большому - лучше асм-контроля не придумаешь! Переживаю за Ваше самочувствие… 😃

Да как сказать Вадим, в принципе конечно геморроя много…
с другой стороны у меги достаточно развитой ассемблер…
я уже начал писать драйвер экрана, запустил внутренний таймер… уже нашел первые грабли (разбираюсь сейчас с помощью радиокота)…
но в остальном - главное четко видеть алгоритм… а язык программирования уже зачастую вторичен (я до VCoder вообще на СИ не писал никогда… Дельфи, да Ява)…
зато какой маленький код получается !!!
да и ограничений некоторых сишных нет ! тоже радует… а то си из кодевижна иногда напрягал своими стандартами…

блин… статистики мало… нужно чтобы народ по заливал VCM и ответил работает навигация по меню или нет…
тогда и будет понятно - проблема только твоего железа или в коде…

Пробовал залить VCM, навигация по меню не работает, нет действий на нажатие кнопок, первая версия работает без проблем

Пробовал залить VCM, навигация по меню не работает, нет действий на нажатие кнопок, первая версия работает без проблем

😦 плохо…

ладно, все равно переписывать все 😃 спасибо за тесты !

Залил VCM от 14.02 . Все работает. Курсор гуляет неправильно, но об этом где-то уже написано.

Не могу понять, вторая версия прошивка доделана или нет?

нет… второй прошивки еще нет…

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

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

Не совсем понятен ход Ваших мыслей. Прошивка пишется русскоязычная. Максимальный фунционал и прочие фкусности.
ИМХО конкуренции ТАКОЙ прошивке от ув. АФТОРА нет и не предвидится, как бы он ни оформил меню. Скорей бы уже❗

Есть нескромное предложение:
может всем миром скинемся и простимулируем.
Ведь труд огромный, а любой труд должен быть оплачен!
Ато у нас ИЖДИВЕНЧЕСТВО какоето получается.
Прям неудобно както…

Владимир Балабардин, +1

Есть нескромное предложение:
может всем миром скинемся и простимулируем.
Ведь труд огромный, а любой труд должен быть оплачен!
Ато у нас ИЖДИВЕНЧЕСТВО какоето получается.
Прям неудобно както…

Предложение уже звучало, но что-то не пошло…
Лично я за!

Думаю надо дождатся ответа Виталия.

Предложение уже звучало, но что-то не пошло…
Лично я за!

Присоединюсь,хоть и не
шибко дружу с программатором

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

Думал об этом… но блин, какой же русский язык красивый… и длинный 😦
Да и идея программирования модели отличается сильно от родной прошивки…
так что: к сожалению пока не вижу как это можно сделать…
если кто сможет предложить - то я с удовольствием рассмотрю варианты ! (в принципе вроде бы на мою “глухоту” к пожеланиям никто не жаловался 😃

В общем как обещал - переписываю движок…

с учетом пожеланий переписал и движок меню и драйвер клавиатуры
по клавиатуре вряд ли вы заметите разницу. (хотя она есть !)

по меню - сделал и цикличный переход, и смещение меню только на краю экрана…

в общем попробуйте, чтобы потом не выявилось что у кого то кнопки не работают… 😃 а то я весь моСК сломал почему VCM не у всех работала…

A-Coder.hex.html

в принципе вроде бы на мою “глухоту” к пожеланиям никто не жаловался 😃

Скорее наоборот. Есть со времен IBM OS2 понятие “эффект второй системы”. khpi-iip.mipk.kharkiv.edu/library/extent/…/V.htm Если до этого не читали, прочитайте. Еще есть басня Михалкова-папы “Ералаш”. Иногда наступаете на те же грабли.
Русский язык он такой. Когда у нас еще не было рок-музыки (конец 60-х начало 70-х), многие на полном серьезе утверждали, что она у нас в принципе невозможна именно по этой причине - слова длинные. Как-то рассосалось.

Имею некий опыт создания интерфейсов на подобных строчных индикаторах. На самом деле сильно придумывать не надо. Все уже сделано и неплохо. Берем любой мобильник, фотоапарат, навигатор и т.п. и смотрим там как движется курсор, какие клавиши и как использовать… Мне в плане меню нравятся современные мобильники SAMSUNG - очень доступная навигация.
Залил A-Coder. При первом взгляде главное меню воспринимается как один обзац текста, пока не вчитаешься. Чтоб такое впечатление не возникало стороки в меню надо обязательно разделять.
Можно так:

Или хотя бы так:

>
>
>
Взгляни беглым взглядом на мой пост и сразу видно где текст, а где меню.
Навигация по меню тоже должна быть быстрой и удобной. В мобильных устройствах принято навигацию делать джойстиком плюс две клавиши для подтверждения/отмены.
У нас надо аналогично. Вверх/вниз мы двигаем правильно. а для выхода/входа в пункт меню надо использовать клавиши +/-. Клавиши меню/выход в общем случае могут дублировать +/- (как сделано сейчас) и дополнительно только они должны использоваться для “критических” операций.
Это чтоб не было такого как в предыдущей версии. Поставил курсор на “FORMAT VD”, и нажал MENU (ну может чуток и передержал). А она мне пишет - отформатированно успешно…

для меня проще вход в меню делать все таки по нажатию кнопки MENU и выход по нажатию кнопки EXIT…
чтобы небыло путаницы при изменении каких то параметров - которые как раз будут меняться кнопками +\-…

На счет критических нажатий - это в существующем драйвере кнопок меню не возможно… если заметили нажатия на кнопки меню во второй версии теперь разные:

• есть нажатие Push\Up - нажали и отпустили, только после этого возможна генерация следующего срабатывания кнопки
• и есть нажатие Push\Hold - это с прошлой версии, нажали и пока удерживаем идет срабатывание кнопки…

первый тип нажатия (Push\Up)- используется при навигации в меню, подтверждениях (MENU\EXIT), изменения параметров с малым количеством значений (например количества каналов PPM)

второй тип нажатия (Push\Hold) - используется при изменении параметров с большим количеством параметров (подстройка процентных значений, изменения длительности пауз)

так что теперь передержать кнопки навигации или подтверждения просто не возможно 😃

Да, дело привычки штука серьезная. Чтобы понять лучшее - его надо попробовать.
Пока у тебя экспериментальный вариант попробуй продублировать MENU\EXIT на кнопки +/-. А мы посмотрим. Я думаю управление одним пальцем гораздо удобнее чем двумя руками. Тут надо немного попользоватся и обратно уходить уже не захочется. Путаницы быть тож не должно, наоборот все логичнее получается. +/- только для входа/выхода из меню. Изменение значений параметров клавишами Up/Down - сразу понятно где увеличение, где уменьшение (при этом изменяемый параметр надо предварительно выбрать клавишей “-” и выделить изменяемое значение инверсией. Возврат к меню клавишей “+”. ).

Давай сделаем - пусть народ понажимает и скажет как действительно удобней.

По клавиатуре опять мы делаем серьезную ошибку. Во первых ты усложняешь программу, во вторых опять получается не совсем логично. Посмотри как работает комповая клавиатура. Любое нажатие сразу генерит символ (именно сразу, а не при отпускании) если клавиша осталась нажатой еще какое-то время то начинается переодический повтор. Все просто и главное - всем нравится.
Ни в коем случае нельзя делать по отпусканию. Мы так устроены, что нажав кнопку сразу должны услышать желаемый “пик”. Если мы его не слышим или даже слышим с задержкой - то первая реакция людей это посильнее надавить на кнопку. У меня доходило до поломок оборудования…

Извини, что немного критикую. Но мне кажется - Вы пытаетесь клавиатурными наворотами как раз решить некоторые нелогичности интерфейса. В итоге получаем только усложнение. Клавиатурный драйвер должен быть отдельной процедурой. Нельза интерфейс подгонять под различные типы нажатий и т.п.

На самом деле многие мобильные устройства ипользуют различные варианты нажатий. Это делается для возложения нескольких функций на одну кнопку. Например можно сделать долгое нажатие EXIT как выход сразу в главное меню из любого пункта. Но нам итак памяти мало. Все должно быть максимально просто и удобно.

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

“Пик” называется “feedback”.
Обработку “по отпусканию” удобно применяеть, когда мы ходим по меню и когда мы используем длительные нажатия. Если делать “по нажатию”, то тогда надо потом все равно ждать отпускания, а это потеря времени. Чтобы с уверенностью различать дребезг контактов и отпускание надо выжидать до трети секунды. Это очень неэффективный способ.
При плохом качестве кнопок простым способом различить быстрое двойное нажатие и дребезг контактов практически невозможно.
Тактовые кнопки, применяемые в аппе плохого качества. У меня уже сдохла Down. И с дребезгом там наверняка паршиво. Так что “по отпусканию” вынужденное разумное простое решение.
Но там, где это не вызовет противоречий можно применять и по нажатию. Вызов меню - по нажатию, навигация по меню - по отпусканию.
Обработка по нажатию и потом отслеживать отпускание и удержание при нехватке памяти излишество. При качестве кнопок в аппе надо ориентироваться на нажатие кнопок не чаще двух раз в секунду.

Тактильные кнопки тем и знамениты что дребезга на них практически нет! Вот надежность - это несколько другой вопрос. А кнопок с дребезгом в 0.3 сек я думаю вообще в природе не бывает.
Более того дребезг есть при нажатии и при отпускании. Поэтому программе обсолютно “фиолетово” что отслеживать. Это решает только программист.
И еще. На входе коннтроллера на всех кнопках стоят RC цепочки. Они специально предназначены эффективно подавлять любой дребезг.

гм… мужики а вы попробовали a-coder который я выложил ?
​ в нем как раз и сделано срабатывание по нажатию, а не по отпусканию (В отличие от vcm)

в меню НАСТРОЙКА ПЕРЕДАТЧИКА \ НАСТРОЙКА КНОПОК МЕНЮ есть три параметра:
Задержка Push\Up - это задержка при нажатии кнопки до генерации кода… генерация по умолчанию идет после 10 мс… потом ждем отпускания кнопки (то есть для пользователя срабатывание кнопки будет именно по нажатию а не по отпусканию)
​
Задержка Push\Hold - это как раз задержка между генерацией кодов кнопок… то есть нажали и держим и каждый период генерируется код кнопки… по умолчанию значение 10… но наверное стоит увеличить хотя бы до 15 чтобы комфортно изменять некоторые значения…

Кстати, я не знаю что за цепи стоят на кнопках - но дребезга там за глаза… 😦

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

Так реализовано в VCoder’e, но как показала практика это не всегда удобно… примеры когда нечаянно пролетали 2 уровня меню и стирали модель в памяти (а после этого канал 3 = 1500 мкс - двигатели модели на середину тяги!!) уже были… нечаянно форматировали V-Disk - тоже не самое приятное если EEPROM не сохранен…
да сейчас это пофиксино на уровне доп. запроса на действие… но сам осадочек остался…
поэтому я решил сделать навигацию по меню по нажатиям с отпусканием… кстати попробуйте прошивку, даже при минимальных значениях задержки Push\Up работать очень комфортно… по крайней мере мне (а вот ваших отзывов жду)

Извини, что немного критикую. Но мне кажется - Вы пытаетесь клавиатурными наворотами как раз решить некоторые нелогичности интерфейса. В итоге получаем только усложнение. Клавиатурный драйвер должен быть отдельной процедурой. Нельза интерфейс подгонять под различные типы нажатий и т.п.

Драйвер клавиатуры и есть отдельная процедура…
просто для нее задается какие кнопки отрабатывать в режиме Push\Hold а какие в режиме Push\Up. кстати на удивление на асме все получается достаточно компактно (или это я так асм люблю…) так что потерю около 50 байт на расширенный функционал драйвера я себе простил 😃

На самом деле многие мобильные устройства ипользуют различные варианты нажатий. Это делается для возложения нескольких функций на одну кнопку. Например можно сделать долгое нажатие EXIT как выход сразу в главное меню из любого пункта. Но нам итак памяти мало. Все должно быть максимально просто и удобно.

Чтобы отрабатывать долгое нажатие кнопок нужно делать реакцию на отпускание (чтобы замерить как долго была нажата кнопка) - а мы уже от этого отказались… (буквально один абзатц выше… правда я его поскипал 😃

Да, дело привычки штука серьезная. Чтобы понять лучшее - его надо попробовать.
Пока у тебя экспериментальный вариант попробуй продублировать MENU\EXIT на кнопки +/-. А мы посмотрим. Я думаю управление одним пальцем гораздо удобнее чем двумя руками. Тут надо немного попользоватся и обратно уходить уже не захочется.

Угу… привычка хуже неволи… все ведь так и привыкли в VCodere что кнопка влево (+) уменьшает значение, а кнопка вправо (-) увеличивает 😃)
прямо и не знаю стоит ли вернуться к значкам на кнопках или оставить как было в первом VCodere 😃) пока сделал как на кнопках (то есть + это увеличние, а - это уменьшение)

Путаницы быть тож не должно, наоборот все логичнее получается. +/- только для входа/выхода из меню. Изменение значений параметров клавишами Up/Down - сразу понятно где увеличение, где уменьшение (при этом изменяемый параметр надо предварительно выбрать клавишей “-” и выделить изменяемое значение инверсией. Возврат к меню клавишей “+”. ).
Давай сделаем - пусть народ понажимает и скажет как действительно удобней.

Вот этот путь как раз мне не понравился…
как то показалось привычнее встал на пункт и если у него одинарное значение то кнопками + или - меняем значение…
если значение двойное, тройное (это будет в настройках каналов) - то нажатием MENU проваливаемся в подменю и там уже настраиваем каждый параметр в отдельности…

кстати хорошая новость - у меня в голове вроде бы окончательно оформилась реализация логических условий, так что в связи с этим все точки каналов будут настраиваться в одном месте… а не как было в VCoder что крайние точки в одном месте а центральная в другом…

параллельно практически додумал как решить задачку которую подбросил в приват diwski с настройкой реверсивного регулятора (там все изменения идут от 1000 до 1500 в одну сторону и от 1500 до 2000 в другую - но проблема в том что нужно либо первый либо второй диапазон растягивать на весь ход ручки), ну и решиться проблема с возникновением нежелательного диференциала рулей при изменении положения средней точки (а вот крайние менять то нельзя !)…

в общем наконец то у меня в голове кирпичики складываются… а когда они складываются я начинаю писать очень быстро…

p.s. вчера еще нашел небольшую мат. библиотеку для умножения\деления чисел на асме… ! (спасибо радиокоту)

Вчера накидал структуру меню A-Coder.hex.html
теперь буду добавлять редактирование параметров…

p.s. кстати ищу примеры кода работы с Flash памятью (памятью программ)… многие параметры работы прошивки буду хранить не в eeprome (которой ой как не хватает в 64меге) а прямо в программной памяти…

В недалеком прошлом написал несколько десятков программных проектов для метро. И не разу не столкнулся с таким понятием как дребезг. Первые усторойства уже лет 10 на вагонах почти круглосуточно колесят.
Поделитесь в кратце. Как Вы обрабатываете нажатие? И с какой переодичностью опрашиваются кнопки?

если кнопки опрашивать в прерывании - то с дребезгом проблемы редко возникают…
а вот если стоит задача максимально облегчить прерывания - то получаем непрерывный опрос кнопок в главном цикле
прерывание используется только как генератор счетчика с частотой 100 гц…
чтобы не быть голословным - вот что в прерывании:

; Прерывания

TIMER0_INT: ; Внутреннее прерывание
; Используется как счетчик временных периодов
PUSH temp

IN temp , SREG
PUSH temp ; сохранили значения регистров

LDS temp , COUNTER100 ; увеличим значение счетчика
INC temp

CPI temp , 99 ; если значение счетчика меньше 100
BRLO TIMER0_INT_M1 ; то сохраним его
CLR temp ; иначе сбросим счетчик в ноль
TIMER0_INT_M1:
STS COUNTER100 , temp ; сохраним значение счетчика

CLR temp ; установим начальное значение счета
OUT TCNT0 , temp

LDS temp , BEEP_CURR ; уменьшаем счетчик звучания бипера
CPI temp , 0 ; если его значение не нулевое (если
BREQ TIMER0_INT_M2 ; звук звучит)
DEC temp ;
STS BEEP_CURR, temp ;

TIMER0_INT_M2:
POP temp
OUT SREG , temp
POP temp

RETI

то есть ничего кроме генерации последовательности в прерывании не делаем ! ну еще следим за звуковым счетчиком…

А вот чтение нажатых кнопок вызываем непрерывно в главном цикле программы…
Loop: CALL MNKR_READER
… ; здесь печать меню или полетного экрана, чтение стиков,
… ; расчет пачек PPM и все остальное !
RJMP Loop

Сейчас главный цикл за секунду успевает выполниться больше 1000 раз… но конечно это не показатель так как пока нет обсчета математики… но ориентировочно на 50 гц выйти хочеться…
все временные задержки при чтении значений кнопок меню считаются относительно счетчика который изменяется в прерывании (COUNTER100)…
поэтому задержки отрабатывают верно и при вызове процедуры чтения кнопок меню 1000 раз в секунду и при 10 разах в секунду…

в прерывание ничего не могу поместить лишнего потому что еще одно прерывание будет заниматься захватом значений PPM сигнала с ученического разъема… его нужно захватить и обработать, а если в моменте изменения сигнала с тренерского разъема мы в другом прерывании - то тут и появляется погрешности чтения, дрожание серв и так далее (по этой причине захвата нет в первом кодере… там обсчет посылок PPM производился в прерывании… следовательно на захват (для другого прерывания) практически не оставалось времени… в итоге раз в секунду-полторы - потеря синхронизации -и провал в посылках ученика… потом восстановление и опять потеря… - в общем не работало стабильно…)

Здравствуйте! Спасибо за первую версию! Интересно, когда вторая выйдет?

Тактильные кнопки тем и знамениты что дребезга на них практически нет! Вот надежность - это несколько другой вопрос. А кнопок с дребезгом в 0.3 сек я думаю вообще в природе не бывает.
Более того дребезг есть при нажатии и при отпускании. Поэтому программе обсолютно “фиолетово” что отслеживать. Это решает только программист.
И еще. На входе коннтроллера на всех кнопках стоят RC цепочки. Они специально предназначены эффективно подавлять любой дребезг.

Друзья! Прошу обратить внимание на то, что дребезг-дребезгу рознь! Нажатие на кнопку в нашем случае означает МГНОВЕННЫЙ уровень нуля на соответствующей кнопке. Отпускание же подавляет любой дребезг в течение примерно 5 мсек аппаратной схемой… Я уже писал об этих измерениях… Уровень перехода был взят 2V. Прошу учитывать эти аппаратные возможности клавиатуры.

по структуре опроса написал на мыло.

Да верно. Емкость 0,1 мкф + сопр 200 Ом + внутр сопр в меге = дадут задержку в несколько миллесекунд при отпускании кнопки.

A-Coder. Заходим в
Настройка передатчика/Настройка V-Disk
нажимаем UP и зависаем.

Кнопки вроде нормально жмутся. Пробовал при 5, 10 все отлично. При 15 и 20 чувствуется небольшая тормознутость. При 30 иногда появляются пропуски. Даже и не понимаю зачем нужен этот параметр. Ставишь 5 (т.е. срабатывание по нажатию как я и предлагал) и все работает просто замечательно. Как не дави хоть быстро, хоть медленно , все отрабатывается сразу и четко.

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

А кнопок с дребезгом в 0.3 сек я думаю вообще в природе не бывает.

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

A-Coder. Заходим в
Настройка передатчика/Настройка V-Disk
нажимаем UP и зависаем.

опс… наверное в описании пункта в указателях ошибочка… сейчас гляну…

гм… по описанию вроде все верно… вечером гляну… 😃

Кнопки вроде нормально жмутся. Пробовал при 5, 10 все отлично. При 15 и 20 чувствуется небольшая тормознутость. При 30 иногда появляются пропуски. Даже и не понимаю зачем нужен этот параметр. Ставишь 5 (т.е. срабатывание по нажатию как я и предлагал) и все работает просто замечательно. Как не дави хоть быстро, хоть медленно , все отрабатывается сразу и четко.

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

Повтор увеличу возможность поставить значение до 50…

Залил, проверил - кнопки работают на славу!

Залил, проверил - кнопки работают на славу!

Так, что, уже есть прошивка новая?

опс… наверное в описании пункта в указателях ошибочка… сейчас гляну…

гм… по описанию вроде все верно… вечером гляну… 😃

A-Coder.hex.html

полтергейст какой то… или я исправил ошибку в векторах как то мимоходом когда другие вещи редактировал… - в меню V-DISKа все работает во все стороны 😃

p.s. кстати написал я все таки модуль самопрограммирования atmega64… так что теперь все настройки передатчика будут храниться в программной памяти и не будут кушать ценный EEPROM… ну а если останется место - то в программной памяти умещу еще и FLASH-диск для хранения уже настроенных моделей… 😃

Так, что, уже есть прошивка новая?

Новая прошивка еще пишется… причем стадия очень ранняя… можно даже сказать что ее скорее нет чем она есть 😃

Глюк в меню ушел. 5 в задержке по умолчанию это нормально. 50 для повтора вполне достаточно будет.
больше изменений не заметил.

Выходные прошли 😃
А-Соder еще немного написался - A-Coder.hex.html

1. Настройки передатчика сохраняются во FLASH… для этого нужно выбрать пункт меню НАСТРОЙКИ ПЕРЕДАТЧИКА \ СОХРАНИТЬ НАСТРОЙКИ

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

3. ПОложено начало универсальному редактору параметров… так что такие блоки как Редактирование каналов ppm, Редактирование внешних значений, редактирование настроек каналов и так далее - теперь отрабатывается одним редактором… Пока все разделы работают только на просмотр (редактор второй очереди еще пишется)

4. Еще что то по мелочи написано и исправлено

Очень много изменений в коде - но как правило пока эти изменения скрыты от глаз и носят скорее обеспечительную функцию для будущего функционала…

кстати размер кода около 8 кб… - очень мало по сравнению с тем же объемом функционала написанного на СИ… но вот при записи в аппу - запаситесь терпением - функционал записи переменных во FLASH расположен в конце FLASH памяти меги - поэтому программатор упорно записывает в мегу все 64 кб кода 😃))

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

1. про смещение нуля экспоненты при триммировании;
2. само триммирование происходит по экспоненте, те при глубокой экспоненте триммирование очень и очень вялое.

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

1. про смещение нуля экспоненты при триммировании;
2. само триммирование происходит по экспоненте, те при глубокой экспоненте триммирование очень и очень вялое.

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

в принципе готов реализовать функционал который опишите вы…
соотсвественно от вас - описание по шагам - что куда отклоняем, что изменяется и на сколько…
только обязательно проверяйте свою идею на нескольких моделях (как минимум на самолете тренере (4 канала), пилотажном (5-6 каналов - по 2 канала на РВ и Элероны), копии (+ закрылки, предкрылки и так далее), ЛК… чтобы не было потом частных случаев

триммер - это как бы отклонение стика…

Триммер - это смещение нуля стика!
Решишь этот вопрос, остальное всё нормально наложится.

в принципе готов реализовать функционал который опишите вы…
соотсвественно от вас - описание по шагам - что куда отклоняем, что изменяется и на сколько…
только обязательно проверяйте свою идею на нескольких моделях (как минимум на самолете тренере (4 канала), пилотажном (5-6 каналов - по 2 канала на РВ и Элероны), копии (+ закрылки, предкрылки и так далее), ЛК… чтобы не было потом частных случаев

Посмотри EEPROM Editor for er9x
Там симулятор есть, можно покрутить повертеть 😉

Виталий!
Залез тут на рцгрупс и нашел вот это:
www.rcgroups.com/forums/attachment.php?attachmenti…
там целая тема на этот счет.
Вы как то в своих коментах оговаривались о том, что возможно прикрутите телеметрию от FrSky к новой прошивке. Думаю, что кроме меня найдется немало заинтересованных в том, чтобы Acoder был максимально совместим с телеметрией этого бренда.

Здорово! Жаль, что вчера вышел передатчик с приёмником но без телеметрии, так как посчитал, что нафик не нужна если нет дисплея на который выводятся данные, а тут такое(((( А отдельно покупать дисплей за 30 у.е. не хоца.

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

Триммер - это смещение нуля стика!
Решишь этот вопрос, остальное всё нормально наложится.

Именно!
так оно и сделано - триммер просто смещает ноль стика…

Виталий!
Залез тут на рцгрупс и нашел вот это:
www.rcgroups.com/forums/attachment.php?attachmenti…
там целая тема на этот счет.
Вы как то в своих коментах оговаривались о том, что возможно прикрутите телеметрию от FrSky к новой прошивке. Думаю, что кроме меня найдется немало заинтересованных в том, чтобы Acoder был максимально совместим с телеметрией этого бренда.

Видел 😃
и еще кучку док видел… и даже где то примеры кода…
это пока планы на будущее…
в текущей прошивки захваченные каналы будут доступны через отдельные переменные “ЗАХВАТ[X]”, где X - номер захваченного канала
а вот телеметрия будет реализована через функции… - их можно будет в прошивке читать, выводить на экран, в зависимости от их значения - менять параметры модели “на лету” (например делать корректировку кривой газа в зависимости от просадки батареи по времени полета)

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

победим 😃
сейчас полным ходом пишу “универсальный редактор параметров” (который в VCoder все параметры менял) - после того как его напишу - интерфейс можно будет считать законченным и возьмемся за не меньшее “веселье” - целочисленную математику на ассемблере 😃))

Для тестов: A-Coder.hex

В прошлой версии не изменялась контрастность при изменении параметра (только при включении устанавливалась)…

кто нить попробовал сохранение параметров во FLASH ? у всех работает ?

по меню:

сейчас реализую следующий функционал редактора параметров (значений каналов, внешних переменных и т.д.)
выбираем строку кнопками UP \ DN
далее нажимаем MENU и будет появлятся подменюшка…
в зависимости от вида редактируемых и функций будет меняться набор и вид пунктов, общий список таков:
РЕДАКТИРОВАТЬ - редактировать параметр (все строку)
ВЫБРАТЬ - выбрать параметр (при необходимости выбора параметра из списка, об этом позже)
КОПИРОВАТЬ - копировать выбранный параметр
ВСТАВИТЬ - вставить скопированный параметр в место выделения курсором
УДАЛИТЬ - удалить строку выделенную курсором, пустое место удалить со смещение нижестоящих параметров на 1 строку вверх
ОЧИСТИТЬ - очистить параметр в строке выделенной курсором

что то нужно переименовать… в этом меню ?

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

При настройке длительности звука игнорируется первое нажатие на + или - при изменении направления регулировки (сначала жмем + несколько раз, затем жмем минус - это нажатие игнорируется, звука тоже нет).
Это справедливо и для настройки дисплея.
В “редактировании модели” такой эффект не наблюдается.

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

функционал подсветки наверное сегодня напишу… не брался еще из за того что не брался за триммеры… но наверное сегодня все таки напишу чтобы у вас была возможность потестить… 😃

При настройке длительности звука игнорируется первое нажатие на + или - при изменении направления регулировки (сначала жмем + несколько раз, затем жмем минус - это нажатие игнорируется, звука тоже нет).
Это справедливо и для настройки дисплея.
В “редактировании модели” такой эффект не наблюдается.

ага… спасибо !! я тоже заметил чтото подобное, но не понял когда этот глюк проявляется !!
я помоему знаю в чем проблема… попробую исправить!!
спасибо за указание на ошибку !

Продвигаемся A-Coder.hex.html

почти дописал редактор параметров…
посмотреть можно на Настройке каналов…
выбираем нужный канал, жмем MENU, выбираем РЕДАКТИРОВАТЬ (и ничего другого!!) и получаем построчное редактирование записи о канале…
теперь тренируюсь писать настроечные таблицы для других редакторов… ничего сложного, просто мороки много когда из за одного параметра меняется формат других…

с кнопками помоему разобрался - посмотрите, оцените

Все на редкость хорошо. Меню интуитивно понятно. Перескакиваний нет. Срабатывание четкое.
Поменяй фонт буквы “ь”. Сдвинь ее вправо или лучше сделай пузо побольше. Сейчас она смотрится как пробел.

Китайцев понять можно. Они пишут и читают справа налево. Поэтому у них и знак “+” слева получился. Но мы то не китайцы?
Предлагаю сразу интерфейс правильный делать, а не китайский. Даже на первой версии правильнее было!

Ну окройте же в винде/мобиле/фотике/МП3 и т.д. любую регулировку или проигрыватель. Всегда движение вверх или вправо ведет к увеличению.

НАРОД! Ну скажите наконец удобно или нет правой кл уменьшать, а левой увеличивать?

Нет, не удобно. +1 к тому что Вы предложили, ну и пусть на кнопке будет +, мы то знаем что там минус.

А на крайняк, и кнопочки местами поменять можно. +1, присоединяюсь к предыдущему предложению.

Новое меню, действительно, понятно, хотя со временем, все же не помешает составить если не инструкцию, то справочник функций. И еще, может это не глюк, но в редактировании модели из пунктов “внешние значения”, “органы управления” и “условия и выражения” выбрасывает в главное меню.

Дааа… как переменчиво общественное мнение 😃
помню когда в VCodere я сделал +(влево) - уменьшение значения, а -(вправо) - увеличение - меня не поняли, и говорили что лучше сделать по людски, вернее по тому как это написано 😃))

Инструкцию в любом случае придется делать… просто вы еще не видите самого интересного (подменю “Действия”) - вот в нем без точного понимания всех “механики” настройки будет просто нечего делать…
по поводы выкидывания в главное меню из других пунктов (кроме Фильтров и Каналов) - так и должно быть - там заглушки стоят потому что функционала пока нет…
усё будет… просто сейчас на работе запары… времени не особо много чтобы писать…

Гм… Роман, я к сожалению плохо представляю себе что у вас за платформа…

опять таки, знающие меня люди уже говорят хором: “проблема любой самодельной конструкции в ее повторяемости”
сейчас с повторяемостью проблем нет (железо штатное)…
а какое у вас железо ?
😃

проц stm32f103rb (64 ножки, 128к flash, 20k sram) внешний eeprom, индикатор пока TIC154 (нормально будет использовать и индикатор из турниджи (в послед.режиме), апарат. USB для заливки прошивок и eeprom ( со стороны компа как флешка) , (возможно будет эмуляция джойстика для симуляторов).
Платы планирую заказать на заводе (двухсторонние с маской), пока с минимальными размерами (по типу fokus-msv), если все получится то будет еще 2 варианта плат под Sanwa VG400 и Turnigy (то что есть у меня).
По поводу програмирования : вся работа переферии (вывод на экран, формирофание PPM, захват хедтрекера, АЦП) через DMA контроллер.
По поводу повторяемости и доп.платки к turnigy: стоимость STM32 меньше чем mega128, и вместо доп.платы к turnigy я думаю проще просто заменить основную плату с более мощным процом, (например как народ делает здесь code.google.com/p/gruvin9x/wiki/PCB ), из минусов пока вижу только шаг ножек проца 0.5 (но при нормальной заводской плате паяется влет). С наличием процов тоже вроде проблем нету.

Роман!
Все, что Вы делаете или планируете сделать заслуживает уважения. НО, Виталий делает прошивку именно для стокового железа. Это кредо, если хотите. Ведь очень немногие моделисты станут морочиться покупкой, сначала турниги или Флайскай, а потом заказом новой материнки от Грувин или от Вас. Сваять её самому доступно единицам… Многие владельцы аппаратур этого семейства вовсе не помышляют что-то менять и вполне счастливы.
Действительно у стоковой аппы не до конца раскрыт потенциал, но если начинать её апгрейдить ТАК как Вы, то лучше задуматься о покупке чего-нибудь более “брендового” с хорошим функционалом.
А ваши задумки достойны отдельной темы или обсуждения в дневнике. Недаром, соответствующие темы на рц групс имеют поддержку на отдельных соответствующих сайтах, специально для этого созданных.

Очень многие проблеммы с функционалом может решить элементарная замена меги 64 на мегу 128. Причем замена 1 в 1, т. е. без переделки платы, обычной перепайкой. Но заниматься этим просто неохота. Это при том, что на работе я имею все необходимое оборудование. А у многих этого просто нет.
Я уж не говорю про полную переделку платы.
Более того под, новое железо надо написать совт. А это - время.
Виталий уже больше года совтину пишет, и мы как можем ему помогаем.

Жаль что сервак грохнулся. Придется свой пост повторить.

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

1. как я писал ранее. выделить под настоящий скролл правое поле во всех строках. Немного сложновато, но максимально наглядно.
2. Упрощенный вариант. В строке заголовка в правом углу выделяем место под 1-2 символа. В зависимости от положения курсора рисуем там значок или символ. Например, в крайнем правом поле, если есть невидимые строки внизу - рисуем стрелку вниз ▼. Если есть строки вверху - рисуем стрелку вверх. В предпоследнем правом поле можно ставить 1 - для первой строки, букву К - для последней строки.
   В итоге можно легко ориентироваться, и главное во всех менюхах можно сделать просто и однообразно.

Виталий! делай второй вариант. Если подумать и нарисовать несколько спец символов, то вполне можно обойтись одним знакоместом в правом верхнем углу. Наглядности будет достаточно.

Роман!
Все, что Вы делаете или планируете сделать заслуживает уважения. НО, Виталий делает прошивку именно для стокового железа. Это кредо, если хотите. Ведь очень немногие моделисты станут морочиться покупкой, сначала турниги или Флайскай, а потом заказом новой материнки от Грувин или от Вас. Сваять её самому доступно единицам… Многие владельцы аппаратур этого семейства вовсе не помышляют что-то менять и вполне счастливы.
Действительно у стоковой аппы не до конца раскрыт потенциал, но если начинать её апгрейдить ТАК как Вы, то лучше задуматься о покупке чего-нибудь более “брендового” с хорошим функционалом.
А ваши задумки достойны отдельной темы или обсуждения в дневнике. Недаром, соответствующие темы на рц групс имеют поддержку на отдельных соответствующих сайтах, специально для этого созданных.

+100
у Виталия с кодом под родную-то железку еще работы невпроворот…
Нельзя объять необъятное…

Кстати, если Виталий решит ставить доп.платку то можно перевести экран в послед.режим и освободится минимум 6 портов контроллера

Виталий!
Может выложите тест-версию Acoder от 31.03 или следующую. А то ту, что Вы выкладывали, слопал глючный сервак.

A-Coder.hex.html

Сейчас придумываю как написать редактор Условий\Выражений - там структура сложная получилась…

в настройках каналов лучше поставить:
ЗАДЕРЖКА УВЕЛИЧ
ЗАДЕРЖКА УМЕНЬШ

Виталий, хотелось бы узнать - есть ли продвижения?
Просто пришла аппа - хочется перешить (родная прошивка не устраивает отсутствием тренерской составляющей и микшеры не работают - аппа от Авионикса, номера прошивки не смотрел, но микшеры точно не работают… Аппа планируется под FPV…).
Ваши наработки мне понравились, прочитал полностью обе ветки, остановился на этом проекте, но как понял - прошивки (в смысле готовой для полетов) пока еще нет… Только пробы менюшек?

в настройках каналов лучше поставить:
ЗАДЕРЖКА УВЕЛИЧ
ЗАДЕРЖКА УМЕНЬШ

Эхх… я тоже об этом думал - но не нравиться мне такая формулировка 😦

Виталий, хотелось бы узнать - есть ли продвижения?
Просто пришла аппа - хочется перешить (родная прошивка не устраивает отсутствием тренерской составляющей и микшеры не работают - аппа от Авионикса, номера прошивки не смотрел, но микшеры точно не работают… Аппа планируется под FPV…).
Ваши наработки мне понравились, прочитал полностью обе ветки, остановился на этом проекте, но как понял - прошивки (в смысле готовой для полетов) пока еще нет… Только пробы менюшек?

из готового только VCoder (из соседней ветки дневника)

вторая версия еще пишеться… использовать ее не возможно потому что функций генерации ppm там пока нет…

Какие то мелкие правки и устранения глюков: A-Coder.hex.html

Спасибо! Да про Vcoder я прочитал… В нем мне нехватает входа для тренера а так все классно (по описаниям - пока сам не пробовал). Вот и думаю - подождать эту прошивку или прошиться вначале VCoder
И еще вопросик - у меня програматор Мастеркитовский 910, не могли бы вы кинуть фотку какие резюки коротить…
Спасибо за Ваш труд!
С уважением Александр.

Главное - резюк на выходе RST короти… а лучше - все на выходных цепях, не ошибешься.

И еще вопросик - у меня програматор Мастеркитовский 910, не могли бы вы кинуть фотку какие резюки коротить…

Резисторы замкнуть. Диоды тож замкнуть. На вход ставить два стабилитрона.
Читайте ветку про программирование.

Да про Vcoder я прочитал… В нем мне нехватает входа для тренера а так все классно (по описаниям - пока сам не пробовал).
Удачно подключил на первой прошивке Spektrum DX6. Незнаю где Вы такие описания вычитали, у меня всё работает. Если будут вопросы по этому, то в ЛС.

Да про Vcoder я прочитал… В нем мне нехватает входа для тренера а так все классно (по описаниям - пока сам не пробовал).
Удачно подключил на первой прошивке Spektrum DX6. Незнаю где Вы такие описания вычитали, у меня всё работает. Если будут вопросы по этому, то в ЛС.

Спасибо за предложение… Я в первой ветке по вкодер читал, что сам Виталий писал о том, что захвата ппм в прошивке нет… Может и ошибся… Вам я напишу чуть позже - у нас ШОК! Слежу за новостями…

Резисторы замкнуть. Диоды тож замкнуть. На вход ставить два стабилитрона.
Читайте ветку про программирование.

диоды можно не замыкать… достаточно резисторов… и если не поможет попробовать убрать кондер с цепи RESET у меги на плате аппы…
в принципе после этого я думаю никаких проблем быть не должно…

если же они есть - то настаиваю на неправильном подключении программатора !! (неплохо бы это проверить еще раз до того как начнете перемыкать и выкусывать 😃))

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

A-Coder.hex.html

добил строчную запись в редакторе “Условия\Выражения” A-Coder.hex.html

кстати, кто то уже смотрел ? насколько понятно создание условий ?

по операциям наверное доп. комментарий нужен только по
PS - это модуль числа (позитивное значение)
NG - это инверсия логического значения

Теперь настало время поговорить о микшерах, потому что все наши грабли функционала потом идут от них.
пока такая структура у меня

MODEL_MIX:            .BYTE        64*8        ; 64 микшера по 8 байт
байт 1 MODE - режим микшера:
        7 6 5 4 3 2 1 0
        | | | | | | | +--- MIX_ON:      0 - микшер выключен, 1 - микшер включен
        | | | | | | +---- IFOP_ENABLE: 0 - без условия, 1 - есть условие работы микшера
        | | | | | +----- DEST_TYPE:   0 - получатель LCH, 1 - получатель тип значения
        | | | | +------ PROC.DN_TYPE:0 - PROC.DN число   1 - PROC.DN тип значения
        | | | +------- PROC.UP_TYPE:0 - PROC.UP число   1 - PROC.UP тип значения
        | | +-------- CURVE_ON:    0 - кривой нет      1 - есть кривая
        | +--------- CURVE_TYPE:  0 - задан номер кривой, 1 - номер из типа значения
        +---------- MIX_DEF:     1 - микшер задан, 0 - микшер не задан
байт 2 IFOP    - номер условия работы микшера если есть IFOP_ENABLE
байт 3 DEST - получатель микшера
байт 4 SOURCE - источник - тип значения
байт 5 PROC.DN - процент микширования вниз
байт 6 PROC.UP - процент микширования вверх
байт 7 СURVE   - кривая
байт 8 - резерв

Закладываю возможности

1. включения\выключения отдельного микшера (через меню Действия)

2. работу микшера по условию и без него (наподобие SW в VCoder)

3. Спорный вариант - куда передавать результат микширования - в LCH или в какую то внутреннюю функцию - в принципе пока кроме LCH получателя не знаю… - над этим нужно подумать - возникает ли необходимость результат микширования передавать еще куда то, а не в канал ?

4. Закладываю два отдельных процента микширования - от минимума к середине канала и от середины к максимуму - это нужно для построения миксов корректировки поведения модели например на РН - так как обычно есть неравномерность поведения модели при отклонении РН влево и вправо (нужны разные углы)

5. Конечно процентные значения отклонения можно будет брать откуда угодно (значение типа)

6. кривые теперь будут в микшерах, значения кривых будут накладываться на ИСТОЧНИК ! и после этого микшироваться - это чтобы расходы при использовании кривых регулировались правильно и не приходилось как в VCodere использовать промежуточные виртуальные каналы

7. Номер кривой тоже можно будет задавать гибко во время полета

Чего еще не хватает ?
точку OFS нужно вводить ?

3. В вертуальный канал.
4. Очень правильно.
5. Было бы очень полезно, когда после наложения экспонент (может не для п.6, но в тему), мах выходное значение не пересчитывалось по формулам, а было приравнено к +100 и -100% как и до применения экспонент. Это есть в заводской прошивке. Очень удобно.
   Точку OFFSET вводить обязательно!!!

За время отпуска удалось уделить время проекту

A-Coder.hex.html

Пока дошел до следующего способа настройки моделей:
будут разделы:

1. Стандартная настройка
2. Расширенная настройка

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

далее, если стандартные настройки сделаны, то можно через меню Расширенные настройки сделать дополнительные настройки модели… либо исправить стандартные…
в принципе для гурманов останется вариант полностью работать в Расширенных настройках без Стандартных, но сразу замечу что использование по максимуму стандартных настроек модели будет здорово экономить память при сохранении модели
Очень нужны варианты настроек для планеров и вертолетов… кто может написать?

Если кому влом качать и заливать прошивку - вот какие пункты настройки там уже есть

СХЕМА ЭЛЕРОНОВ - 1 РМ\2 РМ\ЛК (1 серва\2 сервы\Летающее крыло соответственно)
ЛЕВЫЙ ЭЛЕРОН - указывается канал для левого элерона, по умолчанию 1
ПРАВЫЙ ЭЛЕРОН - указывается канал для правого элерона, по умолчанию 6
При нажатии на кнопку MENU на пунктах ЛЕВЫЙ ЭЛЕРОН или ПРАВЫЙ ЭЛЕРОН - запускается меню настройки соответствующего канала (мин, середина, макс, реверс, задержки изменения)
НАСТРОЙКА ФЛАПЕРОНОВ - переход в меню настройки флаперонов, доступно только для схемы элеронов - 2 РМ
СХЕМА РУЛЯ ВЫСОТЫ - 1 РМ\2 РМ\V-ХВОСТ (1 серва\2 сервы\V-хвост соответственно)
ЛЕВЫЙ РУЛЬ ВЫСОТЫ - номер канала, по умолчанию 2
ПРАВЫЙ РУЛЬ ВЫСОТЫ - номер канала, доступно для схем руля высоты 2РМ и V-ХВОСТ, по умолчанию 8
настройка каналов так же нажатием кнопки MENU на соответствующем пункте
РУЛЬ НАПРАВЛЕНИЯ - номер канала, недоступно если выбрана схема руля высоты V-ХВОСТ, по умолчанию 4
МИКС ЭЛЕРОНЫ-РВ (КРЕН) - микс элеронов на РВ по крену
МИКС РВ-ЭЛЕРОНЫ (ФАЗА) - микс руля высоты на элероны, движение в одной фазе
МИКС РВ-ЭЛЕРОНЫ (ИНВ.) - микс руля высоты на элероны, движение в противофазе
МИКС РН-ЭЛЕРОНЫ - микс руля направления на элероны для предотвращения крена при работе рулем направления

сейчас по всем рулям добавлю настройку двойных расходов…
так же добавлю настройку номера канала газа…

меню НАСТРОЙКА ФЛАПЕРОНОВ выглядит так

ВЫКЛЮЧАТЕЛЬ - выключатель флаперонов
ВИД ЗНАЧЕНИЯ - откуда брать значение угла отклонения
ЗНАЧЕНИЕ - угол отклонения флаперонов

соответственно иду по функционалу флаперонов: сначала включили режим, затем установили угол - чтобы была возможность если это нужно - регулировать угол в полете…

Виталий, а есть возможность прикрутить прям щас выход ппм?? что бы хотя бы в симе попробовыать повертеть прошивку???

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

Регулировки двойного расхода… каркас + выбор канала для двигателя и настройка Глушения двигателя (тоже каркас) A-Coder.hex.html

Господа, у меня вопрос,

кривую применяем к значению источника, чтобы потом полученное значение смикшировать на получатель…

а OFS - куда прикручивать ? тоже к источнику ? (я так понимаю это смещение центра… ?)

Кстати, никто не видел на асме реализацию на алгоритме Брезенхейма рисования линии ?

А что такое OFS?
Я вроде видел удобный функционал настроек границ и центров каналов. В последней версии его уже не стало?
Кривые однозначно регулируют плавность и диапазоны ходов стиков. Поэтому их накладывать на источники.

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

то есть параметр смещения центра (OFS) не нужен ?

В последней версии все осталось… это меню “Расширенная настройка” - “Логические каналы”

а в меню “Стандартная настройка” можно выбрать номер канала для той или иной рулевой поверхности, и потом сразу перейти к редактированию канала нажав на кнопку MENU.

На счет менее наглядного - что именно не понятно ?

Просто неоднократно поднимался вопрос необходимости мастера настройки моделей… причем как самолетов так и вертолетов и планеров…
соответственно и появилось 2 варианта настройки моделей:

1. Стандартная настройка, при выборе типа модели в меню “Стандартная настройка” будут предложены настройки именно под самолет, вертолет, планер… вариант настройки под самолет я уже указал выше…
   настройки позволяют полностью настроить параметры модели (номера каналов, настройки каналов, необходимые микшеры, значения органов управления и т.д.)
   если этих настроек недостаточно - то всегда можно произвести более точную настройку параметров моделей через меню “Расширенная настройка” - например внести изменения в стандартные микшеры или добавить свои…

Для “гурманов” останется возможность настройки модели без мастера (с нуля)… хотя я сейчас стараюсь в меню “Стандартные настройки” учесть все часто необходимые варианты настройки - это позволит и память экономить да и упрощает рутиные действия

что именно не наглядно лучше говорить сейчас…

p.s. русский язык вообще очень длинный 😃 иногда очень трудно подобрать синонимы…и одновременно не хочется писать по английски потому что в этом случае теряется весь смысл “русской” прошивки…

вчера все таки написал процедуру рисования линии по алгоритму Брезенхейма… так что теперь можно делать редактор кривых

Я наверно торможу, но я так и не понял что такое OFS и для чего он нужен.
Как и в прошлой прошивке, в последовательноти математики разбираетесь только Вы. Возможно для Вас многие вещи кажутся очевидными, но мы их не знаем. Именно для этого я настойчиво предлагаю рисовать диаграммы или блок схемы. Только так мы можем понимать друг друга.
И сложного то ничего нет. Рисуем параметр (стик), добавляем среднюю точку, вводим значение калибровки, ставим ограничитель, блок наложения кривых, вводим значение триммеров, ставим OFS и т.д. Уже получается наверняка неверная последовательность. Попробуй потом разберись что на что влияет.

Многие русские слова очень хорошо сокращаются. и в этом нет ничего плохого. Если, к примеру, слово количество заменить на кол-во страшного абсолютно ничего не случится.
Чтобы написать хороший интерфейс надо сначала разработать его структуру. Прикинуть сколько символов надо отвести под название, сколько под значение. И в дальнейшем четко придерживаться этой структуры. Сейчас все плывет совершенно непонятным образом.
Например, мы выделяем верхнюю строку под название группы параметров. Если надпись поместили в начало стороки, то во всех остальных меню должно быть строго аналогично!.

По поводу функционала (например упрощенные настройки)- тут личное дело разработчика. Главное чтоб было удобно и правильно работало.

OFS это смещение центра источника…
то есть например если у нас у органа управления заданы параметры:
min 100
mid 500
max 900
то при OFS=10%
при микшировании параметры органа управления будут следующими
min 100
mid 580 (500+(900-100)*10%)
max 900

то есть при установленном в центр органе управления (значение 500) - поскольку значение центра будет взято 580 - микширование будет как будтно орган управления сдвинут от центра в сторону уменьшения…

блин… как бы объяснить по понятнее…

OFS это смещение центра источника…
блин… как бы объяснить по понятнее…

Т.е. Offset - это аналог механического триммера, но с учетом конечных точек.

Т.е. Offset - это аналог механического триммера, но с учетом конечных точек.

Если оффсет будет возможен в каждом микшере, то это очень нужная штука… и триммер для каждого полетного режима становится не нужным…

Математически теперь про OFS все понятно. Спасибо.
А вот то что это вещь необходима я сильно сомневаюсь. Не скажу точно за вертолеты, а самолетам точно не нужен.
Дело в том, что смещая среднюю точку пересчитываются углы наклона характеристик вверх и вниз. В Виталеном примере вниз отклонение будет на 480, а вверх на 320 при одинаковых отклонениях стика. Т.о если отриммировать модель с помощью OFS мы получим нессиметричные чувствительности в средних положениях.
Еще проще говоря - ставим OFS на элероны. При неполных отклонениях стика вправо и влево модель будет в одну сторону крутиться больше чем в другую. Это очень нехорошо.

Еще проще говоря - ставим OFS на элероны. При неполных отклонениях стика вправо и влево модель будет в одну сторону крутиться больше чем в другую. Это очень нехорошо.

Это все легко подстраивается в крайних точках (как в Vcoder1). Кроме того, если нет возможности поставить рычаг сервы строго перпендикулярно и на защелках тяг уже нет резьбы - то оффсет единственный выход… и пусть будет несимметрия (которую легко поправить), главное чтоб оффсет стал расчетной серединой диапазона и от НЕГО отсчитывались кривые и прочие смешения.

параметр смещения центра (OFS) не нужен ?

Нужен! Обязательно!!!

кривую применяем к значению источника, чтобы потом полученное значение смикшировать на получатель…

Наверное лучше на источник. Но только с пересчетом на -100 +100 значение. Т.е. наложив, например, на источник экспоненту и увеличив его значение до обычных 100% получим экспоненту, а мах значения источника останутся на том же уровне.

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

Еще как нужен!!! Именно в самолетах. Без Оффсета теряется смысл работы микшеров в стандартной прошивке. Их просто невозможно использовать! Просто через ж…

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

Нет! Меняется точка перехода нуля!!! Углы меняются от значений плюсового и минусового коэф-нта. Конечно, меняя только оффсет углы также изменятся, но это вторичное его действие. Еще раз скажу - он для точки ноль!

ставим OFS на элероны…модель будет в одну сторону крутиться больше чем в другую. Это очень нехорошо.

Оффсет можно ставить куда угодно. На элероны тоже. Все зависит от задачи. Хорошо это или плохо, каждому - свое. Для меня это просто прекрасно!!! 😎 Без оффсета-грусно… 😦

Похоже никто меня и не понял.
Смещать среднюю точку стика необходимо. Это важно для последующего наложения кривых и правильной работы микшеров. Я с этим даже и не спорю - это нужно.
Вопрос в том - как расчитывать математику в крайних точках. Предлагается два способа:

1. Линейное смещение центра на определенную величину. Тут получается, что смещая центр происходит ограничениние максимально возможного диапазона. Пример: сместив центр на 25% мы на эту же величину ограничим максимальное отклонение, но отклонения остаются линейными в обе стороны.
2. Смещение центра с перерасчетом крайних точек, как предложил Виталий. Сместив центр максимальные отклонения останутся неизменными, но возникает сильная нелинейность при отклонениях в одну и другую строну. Пример: Делаем смещение на 25%. Отклоняем стик вправо на половину - рулевая машинка уходит на 12,5%. Отклоняем стик влево, тоже на половину - рулевая машинка уйдет на 37,5%.

А теперь и подумайте какой вариант лучше и как вообще второй вариант можно использовать на элеронах?

Еще раз объясню на реальном примере. Пусть мы имеем серву которая отклоняется на +/- 30 градусов от центра. Допустим мы ее прицепили на руль направления и получили его отклонение на +/- 30 градусов.

Теперь представим что мы неправильно отрегулировали тягу и чтобы выставить ноль мы смешаем машинку на +10 градусов.
Так вот, в положительную сторону больше чем на +20 градусов мы отклонения получить не сможем никогда!
А с отрицательным отклонением как раз и есть два варианта:

1. Линейное. Отклонение будет до - 20 градусов. Общий диапазон от +20 до - 20 град.
2. Нелинейное. Отклонение можно сделать до -40 градусов. Общий диапазон от +20 до - 40 град.
   Ну и как при втором варианте летать можно?

гм… вообще-то с OFS все немного не так…

В следующем блоке я не правильно описал работу OFS… прошу прощения:

использование OFS для источника работает немного по другому…
это просто аналог тримера органа управления… причем работающий только в одном микшере (где задан OFS)…

применять можно в разных местах… например при включении флапперонов нам нужно чуть брать РВ на себя… применение OFS при включенных флаперонов даст именно эффект дачи РВ на себя…
причем этот микшер отработает именно для флапперонов… отключаем флаппероны - микшер отключается, и все как и прежде… min mid max…

по поводу хода РМ. не совсем корректно говорить про разный ход РМ при движении стика вверх и вниз… - ведь именно для этого OFS и ввели чтобы не отклонять стик вручную… возникнет некоторый дифференциал отклонения рулей - но так для этого OFS и задали… гм… кстати, а какой вариант можете предложить вы ? в принципе еще не поздно сделать по другому…

опять таки остается возможность коррекции не только параметра OFS но и параметров конечных точек каналов (для того чтобы убрать неравномерность)… причем коррекция конечных точек возможна в зависимости от включенного режима полета (а не только при настройке модели)…

опять таки остается возможность коррекции не только параметра OFS но и параметров конечных точек каналов (для того чтобы убрать неравномерность)… причем коррекция конечных точек возможна в зависимости от включенного режима полета (а не только при настройке модели)…

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

гм… вообще-то с OFS все немного не так…

Нашел у себя инструкцию на пульт. Со страницы 47 начинается разбор микшеров. Стр 50 показывает работу офсета.
файл 8мб.

на стр 32 2 рисунка линейной и эксп. зависимости. Это то, что я просил Виталия.

…имеем серву которая отклоняется на +/- 30 градусов…
…мы неправильно отрегулировали тягу и чтобы выставить ноль мы смешаем машинку на +10 градусов.
Так вот, в положительную сторону больше чем на +20 градусов мы отклонения получить не сможем никогда!

Вы описали не оффсет, а триммирование или субтриммирование.

Нашел у себя инструкцию на пульт. Со страницы 47 начинается разбор микшеров. Стр 50 показывает работу офсета.
файл 8мб.

на стр 32 2 рисунка линейной и эксп. зависимости. Это то, что я просил Виталия.

Сейчас гляну !

Добрый,день ! Внимательно слежу за процессом создания новой версии v-coder2 , сейчас благополучно летаю по камере , используя первую версию . Судя по темпам разработки, новая версия может появиться наверное уже к следующему сезону, если у Виталия не пропадет желание доводить это благородное и уважаемое дело до конца . В текущей версии всё устраивает ,работает очень хорошо , правда не очень нравится что результаты триммирования сделаные в полёте ,пропадают ,если их специально не сохранить ,но к этому можно привыкнуть. Если всё будет хорошо, очень хочется всётаки хедтрекер , ну чтоб вообще)) . Вопрос к автору ,не забыл ли он об этой вкусняшке для нашего фпвшного брата? )))

Так в чем же отличие оффсета?
В приведенной таблице я увидел семейство абсолютно линейных характеристик с начальным смещением средней точки. При смещении ручки газа от -100% до +100% мы имеем значение на выходе:
от 0 до 100 при оффсет=100
от 50 до 150 при оффсет=0
от 100 до 150 при оффсет=-100 (должно быть 200, но на 150 наступает ограничение).

Никакого перерасчета на крайние точки нет. Об этом я уже говорил и считаю это правильным.
Вот только триммер дает абсолюно аналогичный результат. Для чего спрашивается огород городить?

Так в чем же отличие оффсета?

Совершенно согласен - никакого…

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

Так ведь триммер к микшеру не присобачишь… а полетные режимы опять?

Получается оффсет это смещение средней точки канала по сути полный аналог триммера. Разница в том, что оффсет расположен в микшере и может быть включен/выключен при изменении полетных режимов.
С другой стороны для каждого полетного режима выставляются свои значения триммеров. Опять получается тот же эффект. Ну разве что диапазон у триммеров поменьше будет.

Виталий! раскажи в итоге, по какой математической формуле ты считаешь смешение оффсета.

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

Выше уже шла речь о включаемом микшере для флапп-РВ, где необходимо настроить оффсет именно в микшере… так что необходимость оффсета вряд ли должна вызывать сомнения…

Да впринципе я не против оффсета. Я уже об этом писал. Мне не совсем понравилась формула представленная Виталием. Это касательно пересчета на крайние точки.

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

1. Триммер сдвигает значение канала на очень небольшую величину. Офсет - на полный диапазон значений.
2. На значение триммера накладываются последующие изменения и вычисления. На офсет - нет.
3. Например мне нужно привязать изменение канала от 0 до +100% (или еще хуже от +20 до +100%) от мастер - канала “ГАЗ”. Который меняется от -100% до +100% Как это сделать без ОФСЕТ? Никак!!! Никакими триммерами не сделать! (по правде сказать, криво и через задницу, можно сделать только подобие , но от таких действий слеза наворачивается…)
4. Офсет с неизменными значениями величин на границах диапазона значений, ИМХО, считаю более удобным.

необходимость оффсета вряд ли должна вызывать сомнения…

Совершенно согласен!

Нашел у себя инструкцию на пульт. Со страницы 47 начинается разбор микшеров. Стр 50 показывает работу офсета.
файл 8мб.

на стр 32 2 рисунка линейной и эксп. зависимости. Это то, что я просил Виталия.

Курил-курил я табличку… не совсем понял 😦

Давайте объясню как это планируется сделать…

Начнем как это не странно с микширования как оно сделано в VCoder

у нас есть следующие параметры микширования
DEST - канал получатель значения микшера
SOURCE - источник микширования (LCH или UCH)
PROC - значение процента микширования

выключатель микшера и регулируемых микшер сейчас не рассматриваем - они всего лишь частные случаи…

как вычисляется микшер

определяем точки диапазонов получателя
DEST_MIN, DEST_MID, DEST_MAX - для канала получателя (надеюсь понятно что первое это минимум, далее средняя точка и далее максимум)

определяем точки диапазонов источника
SOURCE_MIN, SOURCE_MID, SOURCE_MAX - соответственно мин, середина, макс источника… - поскольку и у LCH и у UCH есть эти параметры нам все равно что будет выступать в качестве источника (это я закрываю частный случай когда источником выступает LCH а не UCH)

ВНИМАНИЕ!
использованная точка диапазона SOURCE_MID в новом кодере на этом этапе будет скорректирована при помощи OFS (как расчитывается OFS смотрите ниже в моем ответе msl_272)

далее, определяем значение SOURCE_VAL - вернее даже определяем не значение источника а в каком промежутке оно находиться MIN_MID или MID_MAX
пусть значение источника находиться в промежутке MIN_MID (то есть ручка управления например тягой находиться между нижним и средним положением)

определив диапазон источника запоминаем границы диапазона
SOURCE_START=SOURCE_MIN
SOURCE_FIN=SOURCE_MID
​
теперь давайте под итожим что у нас получилось и переведем дух (с микшерами я мучался долго)
у нас:
SOURCE_VAL - значение источника
SOURCE_START - минимум источника (SOURCE_MIN)
SOURCE_FIN - максимум источника (SOURCE_MID)
​

теперь чуть вернемся назад… и посмотрим какие значения у нас получились если бы SOURCE_VAL находилось в диапазоне MID_MAX
SOURCE_START=SOURCE_MID
SOURCE_FIN=SOURCE_MAX
​
надеюсь что у вас получилось то же самое что и у меня 😃

теперь, передохнув глотнем воздуха и идем дальше:

смотрим на знак процента микширования

если PROC > 0 то диапазоны получателя берем те же что и у источника для первого случая (SOURCE_MIN<SOURCE_VAL<SOURCE_MID):
DEST_START=DEST_MIN
DEST_FIN=DEST_MID
​
для второго случая (SOURCE_MID<SOURCE_VAL<SOURCE_MAX):
DEST_START=DEST_MID
DEST_FIN=DEST_MAX
​

теперь второй случай: PROC < 0 - мы берем противоположный диапазон !
то есть:
для первого случая (SOURCE_MIN<SOURCE_VAL<SOURCE_MID):
DEST_START=DEST_MID
DEST_FIN=DEST_MAX
​
для второго случая (SOURCE_MID<SOURCE_VAL<SOURCE_MAX):
DEST_START=DEST_MIN
DEST_FIN=DEST_MID
​ еще раз отмечу это для PROC<0

теперь рассчитаем:
RES = (DEST_FIN-DEST_START) * SOURCE_VAL * PROC) \ ( (SOURCE_FIN-SOURCE_START) * 100)
​
соответственно это значение и будет значением микшера… его мы прибавим к значению канала DEST

Теперь о триммерах:
триммер это коррекция положения ручки UCH…
то есть мы получаем SOURCE_VAL и потом просто прибавляем к ней значение триммера
SOURCE_VAL=SOURCE_VAL + TRIM_VAL

значение центра канала (SOURCE_MID) здесь не меняется !!!
мы просто микшируем значение как бы дополнительно отклоненную на TRIM_VAL ручку канала…
так же здесь не меняется и значение центра канала получателя (DEST_MID)

Теперь значение OFS
фактически это сдвиг именно средней точки источника, то есть SOURCE_MID… посмотрите как измениться микширование !! особенно если SOURCE_VAL до OFS находиться в диапазоне SOURCE_MIN<SOURCE_VAL<SOURCE_MID, а после OFS в диапазоне SOURCE_MID<SOURCE_VAL<SOURCE_MAX
тем более что в новой прошивке проценты микширования для каждого из диапазонов будут свои (PROC_MIN_MID, PROC_MID_MAX)

Соответственно написанному мною выше попробую прокоментировать то что вы писали о работе OFS и Триммеров

1. Триммер сдвигает значение канала на очень небольшую величину. Офсет - на полный диапазон значений.

НЕТ !!
триммер всего лишь изменяет текущее значение органа управления !!! никаких значений (параметров каналов) он не изменяет, это делается в микшерах
в принципе ничего не мешает сделать диапазон триммеров еще большим… хоть до всего диапазона органа управления… - вопрос только “зачем?”, триммер нужен лишь для коррекции органа управления (а не управления вместо органа управления !)

2. На значение триммера накладываются последующие изменения и вычисления. На офсет - нет.

НЕТ !!!
просто эти параметры по разному влияют на вычисление в микшере.
триммер фактически изменяет значение органа управления, а OFS изменяет точку отсчета для микширования

3. Например мне нужно привязать изменение канала от 0 до +100% (или еще хуже от +20 до +100%) от мастер - канала “ГАЗ”. Который меняется от -100% до +100% Как это сделать без ОФСЕТ? Никак!!! Никакими триммерами не сделать! (по правде сказать, криво и через задницу, можно сделать только подобие , но от таких действий слеза наворачивается…)

это обычно делается изменением диапазона канала… MIN=0%, MID=50%, MAX=100%…
для второго варианта: MIN=20%, MID=60%, MAX=100%
никаких извратов 😃
но нужно учитывать что такие настройки канала будут для всех микшеров… а вот как раз этого иногда нужно избежать…
либо можно это сделать через кривые которые будучи включенные в микшеры позволят сделать подобное…

Получается оффсет это смещение средней точки канала по сути полный аналог триммера.

НЕТ!
OFS - это точка отсчета при микшировании… а триммер это корректор значения органа управления

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

НЕТ!!
См. выше

Виталий! раскажи в итоге, по какой математической формуле ты считаешь смешение оффсета.

ООО!! это я как то упустил…
смещение OFS это фактически смещение средней точки источника
файтически это будет
SOURCE_MID + ( SORCE_MAX - SOURCE_MIN ) * OFS / 200

Обращаю внимание делю всё именно на 200 !! это не моя опечатка… потому что у меня возможны точки -100%, 0, +100%

Совершенно согласен - никакого…

Так ведь триммер к микшеру не присобачишь… а полетные режимы опять?

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

Добрый,день ! Внимательно слежу за процессом создания новой версии v-coder2 , сейчас благополучно летаю по камере , используя первую версию . Судя по темпам разработки, новая версия может появиться наверное уже к следующему сезону, если у Виталия не пропадет желание доводить это благородное и уважаемое дело до конца . В текущей версии всё устраивает ,работает очень хорошо , правда не очень нравится что результаты триммирования сделаные в полёте ,пропадают ,если их специально не сохранить ,но к этому можно привыкнуть. Если всё будет хорошо, очень хочется всётаки хедтрекер , ну чтоб вообще)) . Вопрос к автору ,не забыл ли он об этой вкусняшке для нашего фпвшного брата? )))

в новой версии будет захват внешнего PPM сигнала…
а уж что это будет ученический передатчик или хедтрекер - это уже ваше дело…

кстати все таки не оставляю мыслей для FPV сделать возможность управления камерой при помощи стиков в режиме джойстика (то есть отклонил стик вправо - камера начала двигаться вправо, отпустил стик - камера остановилась в том месте до которого дошла (а не вернулась вслед за стиком)

Виталий, может быть, конечно, глупый вопрос задам… Я понимаю, что форматы EEPROM и самих файлов настроек модели будут кардинально отличаться от 1-й версии, но реально ли как-то конвертировать старый EEPROM в новый формат, чтобы не перенастраивать все модели с нуля? Или это в принципе невозможно?
И еще, что там со схемой декодера для мультиплексированных каналов?

Виталий, может быть, конечно, глупый вопрос задам… Я понимаю, что форматы EEPROM и самих файлов настроек модели будут кардинально отличаться от 1-й версии, но реально ли как-то конвертировать старый EEPROM в новый формат, чтобы не перенастраивать все модели с нуля? Или это в принципе невозможно?
И еще, что там со схемой декодера для мультиплексированных каналов?

гм… боюсь что конвертировать будет нечего… вторая версия прошивки имеет очень много отличий…
с другой стороны - во второй версии планируются мастера настроек, так что настройка моделей значительно упроститься…
я уже указывал выше будут настройки схемы ЛА, каналов для той или иной плоскости управления, режимы ее… в общем вручную создавать нужно будет минимум типа таймеров или каких то извращенных функций…

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

Все вычисления Виталия рисуются элементарным графиком. Нарисовал его от руки и отправил Анатолию. Если он картинку выложит я ее постараюсь прокомментировать.

Да блин… Чем дальше в лес тем, круче партизаны…
С триммерами все понятно, на графике я это народу покажу.
А вот с ОФСетом полная засада выходит. Математически получается ты сдвигаешь source_mid. Следовательно входной сигнал тебе надо пересчитать под новый диапазон. В итоге переменные взаимосокращаются и мы получаем чисто линейную функцию, которая от офсета вообще никак не зависит!!!

вот картинак

только по картинке мы меняем MID у UCH !!!

На картинке внизу красной линеей обозначен ход стика от -100 до +100%. Из него получаем входной сигнал для микшера source от мин до мах. Далее с помощью Виталиных формул мы пересчитываем входной сигнал source в выходной сигнал dest.
Красной линией я нарисовал стандартный вариант когда центры равноудалены от концов мин и мах. Синей линеей я изобразил вариант когда центр выходного сигнала смещен на 50% вверх.
Пунктирная линия будет в случае отрицательного процента микширования proc=-100%.
Все кривые изображены для микшира в 100%. Если процент микширования меньше, то вых сигнал надо умножить на это число. Т.е. линии будут более пологими.
Это я наглядно объяснил график далее сделаем анализ.

С красной линией все понятно. Любое отклонение стика от 0% вызывает линейное отклонение выходного сигнала DEST от его средней точки mid1.
Теперь смотрим на синюю линию. Здесь мы сместили среднюю точку выхода mid на 50% вверх. В итоге мы получаем кривую с изломом в центре. Отклонения стика вправо и влево имеют абсолютно разные результаты. Отклоним стик вправо на 50% (от нуля вправо на три клетки) получим отклонение выхода на 25% (вверх от mid на одну клетку). А если отклоним стик влево на ту же величину, выходной сигнал упадет на 3 клетки вниз!!!
А теперь представьте, что этот стик управляет элеронами или рулями. Вправо одно, влево совершенно другое!

если PROC > 0 то диапазоны получателя берем те же что и у источника

Т.е. сначала формируем диапазоны источника, тогда source_mid будет изменен на значение OFS и только затем новые диапазоны будут присвоены DEST получателю. Тогда на графике будем передвигать MID на оси SOURSE на величину OFS.

В итоге мы получаем кривую с изломом в центре.

В этом случае излома не будет (в 50-ти %-ном диапазоне).

Добавляя триммер мы сдвигаем начальное положение стика на некоторую величину. Т. е. начальная точка будет не в точке 0%, а чуть правее или левее. Соотв выходной сигнал при центральном положении стика будет чуть выше или ниже средней выходной точки dest mid.

Именно так, только триммер войдет в выходной сигнал с учетом всех процентов и кривых, т.к. SOURSE_VAL изменен на значение триммера и

теперь рассчитаем:
RES = (DEST_FIN-DEST_START) * SOURCE_VAL * PROC) \ ( (SOURCE_FIN-SOURCE_START) * 100)

Т.е. меняя режим (кривые) или микшер мы меняем влияние триммера на отклонение сервы.

Все мои предыдущие посты были комментарием к приведенным формулам.
А теперь рассмотрим ОФС.
Данную кривую я на графике пока не нарисовал, пидется представить ее мысленно. Дорисую и положу чуть позже.
Пусть выходной диапазон симметричен, имеем точки на графике DEST min, mid1, max. Вводим ОФС равным 50%, т.е. смещаем точку source mid на три клетки вправо. На пересечении с горизонталью DEST MID1 ставим точку и от начальных точек рисуем наш график.
Ну и кто говорил что излома не будет? Ситуация получается еще более идиотская. При введении положительного ОФС выходной сигнал DEST будет уменьшаться. При отклонении стика влево выходной сигнал будет линеен. При отклонении вправо сигал будет проходить через точку излома и результа будет похож на введение экспоненты.

На пересечении с горизонталью DEST MID1 ставим точку и от начальных точек рисуем наш график.

Это не совсем корректно, точку ставим на пересечении с красной линией, мы ведь изменили ВХОДНЫЕ диапазоны, а MID1 мы сформируем из полученного SOURSE_MID источника…
Стоит, наверное, еще напомнить, что изначально у получателя (DEST) нету ни концов, ни середины… пока мы не сформировали диапазоны источника.

Это не совсем корректно, точку ставим на пересечении с красной линией, мы ведь изменили ВХОДНЫЕ диапазоны, а MID1 мы сформируем из полученного SOURSE_MID источника…
Стоит, наверное, еще напомнить, что изначально у получателя (DEST) нету ни концов, ни середины… пока мы не сформировали диапазоны источника.

получатель DEST это физическая величина выхода микшера. Без концов и середины его существовать не может. Красная линия это как раз частная характеристика связывающая мин/макс источника с мин/мах выхода dest.

получатель DEST это физическая величина выхода микшера. Без концов и середины его существовать не может.

Т.е. как это не может? Ниже четко указано, в какой момент и как образуются концы у DEST…

если PROC > 0 то диапазоны получателя берем те же что и у источника для первого случая (SOURCE_MIN<SOURCE_VAL<SOURCE_MID):
DEST_START=DEST_MIN
DEST_FIN=DEST_MID
​
для второго случая (SOURCE_MID<SOURCE_VAL<SOURCE_MAX):
DEST_START=DEST_MID
DEST_FIN=DEST_MAX

Красная линия это как раз частная характеристика связывающая мин/макс источника с мин/мах выхода dest.

Совершенно верно! Только зачем же Вы настойчиво выдергиваете MID точку их этой частной характеристики? Это не по правилам проекции…

Ну Вы же сами совершенно верно написали. Мы имеем абсолютно четко заданные точки DEST_MIN, DEST_MID и DEST_MAX. Эти точки однозначно задают диапазон выходного сигнала. Они заранее определены и не подлежат изменению при расчетах.
Далее смотрите синюю линию на моем графике. Она имеет излом в центре. Поэтому вычисления результата справа и слева от излома будут отличаться. Для получения универсальной формулы Виталий вводит две временные переменные start и fin. Далее он определяет в какой точке мы находимся (справа или слева от излома) и на этой основе делает присвоения для start fin и считает результат.

Здесь я еще раз показал механизм работы. Отклонение стика пересчитывается в значение сигнала UCH (от -100 до +100% по умолчанию). Далее этот сигнал попадает на вход микшера как сигнал source. При помощи красной кривой значение source пересчитывается в значение DEST. В дальнейшем значение dest даст величину ширины импульса в сигнале PPM (по умолчению от 1000 до 2000 мкс). Поэтому точки DEST_min DEST_max должны быть однозначно определены.
Красных кривых я нарисовал две. одна для 100% и вторая для 50% коэффициента микшера.

Если мы сместим точку source_mid т.е. вводим офсет в Вашем понимании. Согласно математики при сигнале source_mid мы обязательно должны получить значение dest_mid. На графике это будет смещение точки 2 по горизонтали до пересечения source_mid и dest_mid. отсюда получаем излом кривой со всеми вытекающими…

Опять ввод в заблуждение… Согласно логике формирования:

диапазоны получателя берем те же что и у источника

т.е. dest_min=sourse_min
dest_mid=sourse_mid
dest_max=sourse_max
Все, края и середина с этих пор определены, никаких изменений наклонов 50%-ных еще нету. Это линия 1-3 на графике. Это перевод из SOURSE в DEST. Все.
Теперь строим второй график, где по горизонтали располагаем DEST с полученными на предыдущем шаге концами и серединой, по вертикали откладываем RES (выходной сигнал):

RES = (DEST_FIN-DEST_START) * SOURCE_VAL * PROC) \ ( (SOURCE_FIN-SOURCE_START) * 100)

Вот тут, и только тут, мы получаем новый тангенс угла наклона, зависящий от PROC.

Вадим! В принципе, Вы представляете все верно. Хотя как то слишком длинным путем. Два графика здесь совершенно не нужны.

Ваши присвоения dest_min=sourse_min dest_mid=sourse_mid dest_max=sourse_max категорически неверны. Так делать нельзя. И у Виталия такого нет.

Мы имеем всего одну входную переменную SOURCE_VAL. Она характеризует значение на входе микшера.
И мы имеем всего одну переменную результата RES.
И есть всего одна формула по которой из первой переменной получается вторая:
RES = (DEST_FIN-DEST_START) * SOURCE_VAL * PROC) \ ( (SOURCE_FIN-SOURCE_START) * 100)
Мой график и отображает эту формулу графически. И не более того.
Т.К. в формуле есть коэффициент PROC, его влияние я тоже изобразил.

Считаю что немного мы отошли от главной темы. Не думаю что Виталию наша болтовня интересна.
Сейчас я достал русское описание передатчика от FUTABA. Там параметр offset имеется. Есть электонная версия этого описания, но из-за большого размера она не идет по мылу. На днях я его добуду.
Так вот - там все сделано абсолютно логично, да и не думаю что с мировым брендом кто то спорить будет.
Заодно и пальцами вживую поковырять этот передатчик планирую. Скоро отпишусь.

Не думаю что Виталию наша болтовня интересна.

Почему же? Выяснилось, например, что один и тот же триммер имеет разное влияние на результат в разных микшерах…

Мой график и отображает эту формулу графически. И не более того.

Отображал бы, если б был смещен вправо на OFS от середины sourse… вся прямая, а не только точка 2…

Считаю что немного мы отошли от главной темы. Не думаю что Виталию наша болтовня интересна.
Сейчас я достал русское описание передатчика от FUTABA. Там параметр offset имеется. Есть электонная версия этого описания, но из-за большого размера она не идет по мылу. На днях я его добуду.
Так вот - там все сделано абсолютно логично, да и не думаю что с мировым брендом кто то спорить будет.
Заодно и пальцами вживую поковырять этот передатчик планирую. Скоро отпишусь.

Очень интересная ! хочеться сделать так как будет нужно всем !!!

по поводу мануала можно кидать на gorbukov@yandex.ru или выложить на народ (там нет всяких приколов как в ishare или depositfiles и подобных (у меня мобильный интернет - мне постоянно отвечают что мол уже качаешь файл, поэтому тебе скачивать нельзя 😦((

В выходные подключил опять свой многострадальный AVR910 и немного поработал над A-Coder.hex.html

можете посмотреть функционал РЕДАКТИРОВАНИЕ МОДЕЛИ - СТАНДАРТНАЯ НАСТРОЙКА (для самолетов !! для вертолетов и планеров читайте ниже в этом же сообщении)

пока не до конца написаны только микшеры…
микшеров для самолета у меня получилось пока 4

1. микшер по крену элероны->рв (когда у нас 2 РМ на РВ)
2. микшер по тангажу рв-элероны (фаза) (когда у нас 2 РМ на элероны) - движение РВ и элеронов в одной фазе
3. микшер по тангажу рв-элероны (инв.) (когда у нас 2 РМ на элероны) - движение РВ и элеронов в противофазе
4. микшер увода рн-элероны - для компенсации крена возникающего при работе РН

Микшеры флаперонов есть…
вопрос какие микшеры еще нужны ?

вообще посмотрите что еще для самолета нужно ?

кстати насколько нужно отключение микшеров вообще (то есть их не использование) ? а то я сделал что каждый из микшеров может включаться или выключаться выбираемым выключателем… но микшеры всегда есть (если нет дополнительных условий их существования вроде 2ух РМ на элероны или РВ)

p.s. все еще жду описание настроек для вертолетов и планеров… выбираться настройка будет соответствующим типом ЛА и далее так же СТАНДАРТНАЯ НАСТРОЙКА (сейчас выбирается но внутри для вертолета и планера просто шаблонные пункты без смысла)

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

например слева взять процент микширования 50% а справа 100%…
тогда OFS будет точкой “перелома”, точкой смены процента микширования !

Желаю поделиться проблемой интерфейса…

пытаюсь придумать как отображать экран с настройками микшеров
имею следующую структуру:

байт 1    MIX_SET            - микшер есть\нет
байт 2    IFOP            - условие работы микшера
байт 3    SOURCE_TYPE        - источник микшера (тип значения)
байт 4    SOURCE_VAL        - источник микшера (значение)
байт 5    DEST_TYPE        - получатель (тип значения)
байт 6    DEST_VAL        - получатель (значение)
байт 7    PROC_DN_TYPE    - процент микширования вниз (тип значения)
байт 8    PROC_DN_VAL        - процент микширования вниз (значение)
байт 9    PROC_UP_TYPE    - процент микширования вверх (тип значения)
байт 10 PROC_UP_VAL        - процент микширования вверх (значение)
байт 11    OFS_TYPE        - смещение микширования (тип значения)
байт 12 OFS_VAL            - смещение микширования (значение)
байт 13    CURVE_NUM        - номер кривой для источника
байт 14 MIX_MASK        - номер шаблона микшера
байт 15 MIX_EDIT        - признак ручного редактирования микшера

Как ее лучше отображать на экране с размером строки в 25 символов из которых 3 символа номер микшера ?
в принципе такие конструкции как:
байт 3 SOURCE_TYPE - источник микшера (тип значения)
байт 4 SOURCE_VAL - источник микшера (значение)
влазиют в 8 символов…
в принципе паузу между колонками можно делать и в пол-символа (3 пиксела).
повторюсь общая ширина 125 пикселов минус 10 пикселов на номер микшера и еще 5 пикселов интервал ( интервал можно уменьшить до 3)

пока в голову пришла только возможность движения по строке (горизонтальный скроллинг) и соответственно накидал примерно такие заголовки

"NN DEST5678 SOURCE78 УСЛ."  - это первоначальный вид
"УСЛ. DN_PROC8 UP_PROC8   "      - один раз нажали "-" (вправо)
"UP_PROC8 OFS45678 CURVE  "    - второй раз нажали "-" (вправо)

ну и так далее, чтобы при каждом нажатии влево\вправо сдвигаться к последнему столбцу который отображался на экране до этого…

может быть ктонить придумает что нить лучше ?
желательно строчную запись в одну строку (это движок меню рисует, не хочеться еще что то писать дополнительно)

А если графически? Стрелка влево-вправо источник-приемник, вверх-вниз проценты, <> - OFS, кривая - $. Короче не станет?

гм… а как графически отобразить например источник ?
или приемник ?
да и источники процентов тоже не знаю как изобразить (особенно если проценты например устанавливаются крутилкой или еще хуже - вычисляются условием\выражением)…

наверное я непонятно написал… проблема не в том виде как написать в заголовке - а как вообще расположить…

ВитГО!
Я пытался на первой прошивке реализовать программу для вертолета,но забросил это дело т.к количество микшеров там переваливает за 18-22.И не все можно реализовать просто и доходчиво.Разобраться в таком количестве микшеров на поле просто не реально.Если делать вертолетную программу то обязательно с заготовленными микшерами автоматов перекоса 90,120,180.
Тогда от этого будет толк!!!

Читаю описание Футабы. Пока только на бумаге.
Для установки рулей у них вводится два понятия. Триммер и субтриммер.
Субтриммер - это установка нейтрального положения каждого сервопривода. Используется для выставления рулувых поверхностей после подключения тяг.
Триммер - тут все понятно. На каждый триммер задается свой шаг и максимальный диапазон.
Еще у каждого триммера есть очень интересный переключатель режима COMB/SEPA. COMB - это когда триммируются одновременно все полетные режимы. SEPA - значение триммера в каждом полетном режиме будет своё. ИМХО вещь очень нужная. В первой версии кодера мне ее очень нехватает.

ВитГО!
Я пытался на первой прошивке реализовать программу для вертолета,но забросил это дело т.к количество микшеров там переваливает за 18-22.И не все можно реализовать просто и доходчиво.Разобраться в таком количестве микшеров на поле просто не реально.Если делать вертолетную программу то обязательно с заготовленными микшерами автоматов перекоса 90,120,180.
Тогда от этого будет толк!!!

Николай, так я об этом и говорю.
меню Стандартная настройка- это именно заготовленные микшеры…
посмотрите самолетную программу - там никаких микшеров руками задавать не нужно…
указываем какие каналы для каких рулей (элероны, рв, рн) используются, указываем тип рулей (1, 2 сервы, или тип крыла, или тип хвоста) - и все микшеры будут построены автоматически и без вашего участия…
дополнительно там же в настройках указываем как включить режим флапперонов (если у нас 2 сервы на элеронах) - так же микшеры создадуться автоматом,
то же самое по двойным расходам, и всяким другим доп. функциям (типа стандартных микшеров РВ на элероны и наоборот)…

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

не поленитесь, залейте последнюю версию А-Сoder - гляньте как реализован самолетный функционал, по аналогии можно сделать вертолетный…
например для меня не понятно по автомату перекоса…
выберем тип 3-120,3-140, 2-90, а дальше ? сервы как то определенным образом ведь располагаются ?
както они нумеруются или может есть названия для них ?
я сейчас просто назвал - передняя, правая, левая, задняя… а как правильно ?

и так далее…
например хвостовой винт - там идет только регулировка шага или регулировка скорости вращения тоже ?
куда и каким образом используется гироскоп ? как и зачем и чем он настраивается?

я полный профан в вертолетах 😦 и программу настройки для них точно не смогу написать без помощи…

Читаю описание Футабы. Пока только на бумаге.
Для установки рулей у них вводится два понятия. Триммер и субтриммер.
Субтриммер - это установка нейтрального положения каждого сервопривода. Используется для выставления рулувых поверхностей после подключения тяг.
Триммер - тут все понятно. На каждый триммер задается свой шаг и максимальный диапазон.

ну в принципе то же самое реализовано еще в V-Codere только в нем
триммер - это триммер органа управления (совпадает с Футабовским понятием)
а субтриммер Футабы это параметр MIDLE канала в V-Coder в каждом полетном режиме…
так что здесь мы ничем не проигрываем… а может быть даже более понятны - потому как что такое субтриммер я узнал фактически от вас сейчас, хотя логически реализовал его просто назвав по другому

Еще у каждого триммера есть очень интересный переключатель режима COMB/SEPA. COMB - это когда триммируются одновременно все полетные режимы. SEPA - значение триммера в каждом полетном режиме будет своё. ИМХО вещь очень нужная. В первой версии кодера мне ее очень нехватает.

гм… помню когда писал V-Coder все наоборот ратовали за отдельные триммеры для полетных режимов
в новом кодере я задумывался об этом… теперь значит подумаю как реализовать

От Футабы
Всего предложено 4 типа моделей: Самолет, планер, мотопланер, вертолет.
Для вертолета следующие варианты автомата перекоса: Н-1, Н-2, Н-3, Н-4, НЕ3, HN3.
Для самолета выбиратся:

• тип крыла: нормальный или летающее крыло.
• тип хвостового оперения: нормальное, V-тип, ailevator (типо раздельные половинки руля высоты с микшером от элеронов)
  Для летающего крыла выбираем из: 2 элерона, 2 элерона + закрылок, 2 элерона+2 закрылка.
  Для нормального крыла то же самое плюс есть режим 1 элерон.
  У летающего крыла выбирается тип руля направления: обычный и WINGLET (два руля напрвления расположены на вертикальных законцовках крыла.

ВитГо.
Гляну на днях.Но вам как допустим обьяснить чтобы вы могли это реализовать?Про автомат перекоса 120 могу разьяснить.Про остальные пока не в курсе.

ВитГо.
Гляну на днях.Но вам как допустим обьяснить чтобы вы могли это реализовать?Про автомат перекоса 120 могу разьяснить.Про остальные пока не в курсе.

по автоматам перекоса мне Дмитрий (HikeR) давал программку которая их реализует… там помоему как раз 3 типа… соответственно микшеры по ним я тоже построю…

давайте я постараюсь в ближайшее время переписать кое какие настройки для самолета и начнем смотреть плотно настройки для вертолетов…

От Футабы
Всего предложено 4 типа моделей: Самолет, планер, мотопланер, вертолет.

гм… а планер от мотопланера отличается наличием двигателя ?
может объединить ? или там еще есть отличия ?

Для вертолета следующие варианты автомата перекоса: Н-1, Н-2, Н-3, Н-4, НЕ3, HN3.

гм… а что это не расшифровано ?

Для самолета выбираются:

• тип крыла: нормальный или летающее крыло.

это уже и у меня есть, + еще выбор одна серва на элеронах или две

• тип хвостового оперения: нормальное, V-тип, ailevator (типо раздельные половинки руля высоты с микшером от элеронов)

это тоже есть, единственное что в понимании футабы Нормальное - у меня это 1 РМ, а ailevator - это 2 РМ

Для летающего крыла выбираем из: 2 элерона, 2 элерона + закрылок, 2 элерона+2 закрылка.

то есть для летающего крыла 2 элевона (первый вариант),
а дальше закрылок - это типа для руля высоты ? или как ?

Для нормального крыла то же самое плюс есть режим 1 элерон.
У летающего крыла выбирается тип руля направления: обычный и WINGLET (два руля напрвления расположены на вертикальных законцовках крыла.

а WINGLET типа в два разных калала для реализации функции тормоза что ли ? в принципе то два руля можно и через Y кабель подключить…

• гм. до этого я не додумал…
  вовремя прочитал - буду переписывать функционал Стандартной настройки самолета (я тут по алгоритмическим соображением затеял перепись) - напишу с учетом написанного выше

спасибо !

а WINGLET типа в два разных калала для реализации функции тормоза что ли ? в принципе то два руля можно и через Y кабель подключить…

Это, видимо, как на B2 - воздушный тормоз на консолях крыла (либо расщепляющийся элерон). Раскрывается с той стороны, в которую нужно повернуть. На второй консоли при этом плоскости остаются в сложеном положении.

p.s. Есть предложение допилить самолетные настройки и запустить генерацию PPM, чтобы прошивкой уже можно было пользоваться. Так баги гораздо быстрее вылезут, чем при беглом просмотре меню. А остальной функционал потом постепенно добавлять в новых сборках.

на счет допилить - с радостью… но к сожалению функционал так толком и не обсуждаем… а переписывать потом написанное очень не хочется…
с теми же микшерами - вроде уже все продумал - ввели OFS… потом все продумал начал думать о Стандартных настройках - вперся в необходимость их как то маркировать при настройке и сохранять…
в общем грабли появляются по мере продвижения даже сейчас, просто не все я озвучиваю а молча переписываю…

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

мотопланер от планера отличается только наличием двигателя ? или все таки выделать отдельно категорию мотопланер ? (если выделять то из за каких настроек ?)

не стоит отдельно мотопланер делать, пусть в планерных настройках будет мотор и всё.

ОК!

Вот в таком духе сделал настройку…
A-Coder.hex

Смотреть в меню СТАНДАРТНАЯ НАСТРОЙКА при выбранном типе САМОЛЕТ (доступны для выбора ЛЕТАЮЩЕЕ КРЫЛО, ВЕРТОЛЕТ, ПЛАНЕР)

теперь настройка выглядит так:
выбираем сколько серв на элеронах (1 или 2)
если выбрана 1 серва то напротив пункта выбора номера канала для правого элерона автоматом ставиться признак “НЕТ” (управление идет по одному каналу для левого элерона)
так же признак “НЕТ” будет ставиться напротив пункта “ФЛАПЕРОНЫ” - так как с одним каналом на элероны этот режим невозможен
далее, такие режимы как ДВОЙНЫЕ РАСХОДЫ и ФЛАПЕРОНЫ могут быть включены (ВКЛ) и выключены (ВЫКЛ)
если режим включен (это кнопками “-”\“+”) то нажатием кнопки MENU на пункте мы попадаем в меню настройки соответствующего режима
обычно это следующие пункты
ПЕРЕКЛЮЧАТЕЛЬ - выбор переключателя одинарных\двойных расходов
ВЫКЛЮЧАТЕЛЬ - выбор выключателя для включения флаперонов
и далее два параметра расхода

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

Добыл русское описание Футабы. Файл весит 40 Мб. Думаю как выложить.
Может кто поможет.

гм… а никак не пожать ?
тогда на народ…

если отклоним стик влево на ту же величину, выходной сигнал упадет на 3 клетки вниз!!! А теперь представьте, что этот стик управляет элеронами или рулями. Вправо одно, влево совершенно другое!

Все правильно. В таком включении (для элеронов) отклонения будут разные.

и кто говорил что излома не будет? Ситуация получается еще более идиотская. При введении положительного ОФС выходной сигнал DEST будет уменьшаться. При отклонении стика влево выходной сигнал будет линеен. При отклонении вправо сигал будет проходить через точку излома и результа будет похож на введение экспоненты.

Именно так!!! Вы все правильно показали на графиках.
Да, сдвигая в сторону мы делаем подобие экспаненты. Получаем 1 точку излома. Величину наклона обоих плечей можно регулировать параметрами Up и Down. Вплоть до того, что можно получить (двигаем стик от -100 до +100) 0-реакции до определенного значения, а затем увеличение выходного уровня до нужной величины.
Понятное дело, что такие извраты для элеронов редко кому понадобятся… А например газ-РВ, газ-РН очень будут к месту, ИМХО.

насколько нужно отключение микшеров вообще (то есть их не использование) ? а то я сделал что каждый из микшеров может включаться или выключаться выбираемым выключателем… но микшеры всегда есть

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

Файл весит 40 Мб. Думаю как выложить.

Файлообменник, народ.

Давно наблюдаю за развитием создания прошивки и вот что я нашол на просторах инета может пригодится:

Удалось пощупать крутые передатчики руками. Так вот - оффсет это вертикальное смещение всей кривой. Получается к выходному сигналу просто добавляется значение оффсета и все!
Так сделано у всех Футаб, именно так сделано и в Спектрум (описание выкладывали выше).
Получаем простую формулу RES = RES + OFSett и без всяких заморочек со средней точкой источника.

Специально для продвинутых Футаба предлагает несколько вариантов кривых на выбор:

1. Линейная - обычная прямая.
2. Экспонента1 - симметричная экспонента вправо и влево. Кривая от центра идет к крайним точкам.
3. Линия - строится по произвольным точкам.
4. Экспонента2 - кривая идет от одной крайней точки до другой. Т.о. на центр графика не попадает. Думаю, именно этого варианта не хватает для регуливки газа, особенно вертолетчикам.

На графике я показал семейство кривых для различных значений офсета. За основу взял линейную кривую при PROC=100%. Темным цветом изображена исходная кривая ( OFS=0%).
Точно так же при изменении офсета по вертикали будут сдвигаться и все остальные типы кривых.

ну по типам кривых именно так было сделано в vcm в принципе тоже буду делать и в a-coder’e

на счет оfs - буду думать…

на счет оfs - буду думать…

😃

Уважаемый, Виталий! Прочитал все страницы про первую версию и про вторую… первую версию залил и она очень понравилась… Вторую с нетерпением ожидаю… На данный момент есть прогресс… ???.. а то тут давно Вы уже не писали что сделали…

к сожалению работа продвигается медленно… на работе запары… 😦

Виталий!
Может Вам уже надоели периодически появляющиеся здесь вопросы “Ну,когда же?” и, все же. Многим не терпится в т.ч. и мне.
Может часть функционала прошивки или хотя бы некоторые хорошо проработанные элементы позаимствовать от других разработчиков? Понимаю, что Вы пишите код на другом языке, но идти по натоптанному (хотя бы по функционалу) легче. Мне очень нравится прошивка от erez (code.google.com/p/er9x/) особенно подкупают гибкость настроек и возможности отображения телеметрии на мониторе передатчика. Ваш Acoder не хуже, а с учетом русского будет привлекательней для россиян.
Кстати, Ваши коллеги не гнушаются 5 долларовых пожертвований. Думаю, Вы совершенно зря неоднократно отказывались от материального стимула за свою нужную многим работу.
Удачи и успеха.

Эхх… Владимир, мне бы не денег (ну если только для того чтобы купить аппу для экспериментов на 128ю мегу… больше не нужно) - а помощи в написании кода…

очень многие вещи которые есть у ER и THUS я регулярно просматриваю…

к сожалению в настоящее время у меня очень много работы поэтому многим своим увлечениям и проектам уделяю времени совсем мало…
но могу вас заверить - работа движется… 😃

Виталий поймите ,ER и THUS для многих,и для меня второстапеное,а ваша русская прошивка первостепенное.Буду продолжать ждать.

так будет выглядеть таблица микшеров (меню Редактирование модели - Расширенная настройка - Микшеры): A-Coder.hex.html

начал описывать редактор микшера… 15 параметров однако… 13 видимых… A-Coder.hex.html

Описал редактор микшера… A-Coder.hex.html

МИКШЕР        - признак работает ли данный микшер
УСЛОВИЕ      - номер условия при котором микшер микширует данные
ИСТОЧНИК\ТИП   - тип объекта откуда брать данные
ИСТОЧНИК\ЗНАЧ. - номер объекта источника
КРИВАЯ   		- кривая для источника (в отличие от VCoder в АCoder'e кривые будут накладываться прямо в микшере на источник и потом полученное значение будет микшироваться в получатель)
ПОЛУЧАТ.\ТИП  - тип объекта получателя
ПОЛУЧАТ.\ЗНАЧ.  - номер объекта получателя
- ПРОЦ. \ТИП    - процент микширования от min до 0 - тип источника
- ПРОЦ. \ЗНАЧ.  - процент микширования от min до 0 - значение
+ ПРОЦ. \ТИП   - то же самое только для от 0 до max
+ ПРОЦ. \ЗНАЧ. - то же самое только для от 0 до max
СМЕЩЕНИЕ\ТИП   - смещение центральной точки источника - тип
СМЕЩЕНИЕ\ЗНАЧ - смещение центральной точки источника - значение

код еще не отлаживал (я на работе сейчас) так что возможны небольшие глюки… 😃

Народ кто нить компрессией текста словарями занимался?
нет хорошего словаря для русского языка ?
а то в прошивке уже 9 кб строк !!! как то многовато… нужно бы сжать…

Может все же немного сами строки в меню сокращать. Хотя в этом и других случаях ИМХО сильно сократить код не получится.

По поводу микшеров я уже много писал. В микшере должна смещатся центральная точка выхода.
“Смещение центральной точки источника” - само понятие абсурдно. Входной сигнал (со стика или любого другого канала) есть физическая величина. Она определена и меняться не может.
А микшер представляет собой некую функцию, которая из входного сигнала генерирует выходной. И тут любые смешения имеют здравый смысл.

Я хочу сказать, что стик или руль можно отклонить вправо или влево на некую величину. К отклонению руля можно добавить или отнять некую постоянную величину например триммера.
Но совершенно нелогично считать отклонение стика вправо от какой то точки смещенной от центра влево.

С интересом начал следить за вашей темой. Не так давно обзовелся сабжевым передатчиком (Turnigy V2).
Есть одно небольшое пожелание по триммерам.
Сперва объясню, что меня не устраивает: тримммер в большинстве случаев служит для настройки самолета на ровный горизонтальный полет, без скольжений и наростающих кренов(в случае с вертолетами или планерами все примерно по той же теме), т.е. фактически это такая величина, которую хотелось бы раз настроить (во время облета модели) и забыть. Но в текущей реализации, если я оттриммировал модель, а после этого внес изменения скажем в расходы стиков, или задействовал экспанентный отклик(функции сами по себе нулевую точку не трогающие), то я теряю свои настройки триммера, т.к. они теперь начинают считаться через ту же экспаненту и следовательно “съезжают”.
Спасают здесь саб-тримы, т.к. их значения никогда и ни куда не “съезжают”. Я для некоторых самолетов прямо так и сделал, после облетки и триммирования, взял и пересчитал на листочке все триммера в их соотвествующие значения сабтримов (с учетом всех миксов и градиентов). После этого доводить настройку модели гораздо легче, т.к. триммеры уже в нуле(перешли в сабтримы) и соответственно все экспаненты и примочки работают симметрично относительно моего ровного полета.
Предложение: Добавить функцию (либо на кнопочку, либо на менюшку в настройках модели), которая бы пересчитывала текущие значения триммеров в соотвествующие значения сабтримов и суммировала их к уже существующим значениям, а триммера после этого сбрасывала в ноль. Т.е. технически эта функция должна пробежать по всем миксам пользователя, получая на вход отклонения стиков, равные соответствующим триммам, а на выходе значения для отклонения соответствующих серв, но сервы отклонять, конечно, не надо, а просто добавляем эти значения к сабтримам.

сделан редактор микшеров A-Coder.hex.html

Может все же немного сами строки в меню сокращать. Хотя в этом и других случаях ИМХО сильно сократить код не получится.

По сокращению строк в меню - готов выслушивать !

Конечно это не тот алгоритм компрессии который я имел в виду, но если это поможет меню стать более прозрачным и понятным - то я только за… скажите что и на что переназвать !

По поводу микшеров я уже много писал. В микшере должна смещатся центральная точка выхода.
“Смещение центральной точки источника” - само понятие абсурдно. Входной сигнал (со стика или любого другого канала) есть физическая величина. Она определена и меняться не может.
А микшер представляет собой некую функцию, которая из входного сигнала генерирует выходной. И тут любые смешения имеют здравый смысл.

Давай тогда закрепим !

Смещение (OFS) будет назначать точку центра выходного канала при микшировании…

так пойдет ?

Я хочу сказать, что стик или руль можно отклонить вправо или влево на некую величину. К отклонению руля можно добавить или отнять некую постоянную величину например триммера.
Но совершенно нелогично считать отклонение стика вправо от какой то точки смещенной от центра влево.

почему не логично ?
смещение центра при помощи OFS фактически эмулирует отклонение стика (для текущего микшера где OFS задан).
то есть например в нулевом положении стика, сдвинув OFS например на 10% вниз - получаем как бы отклоненный вверх стик (еще раз повторюсь для одного микшера!) и наоборот…
смысл смещения для источника есть !

в принципе перенеся это смещение на выходной канал можем получить тоже самое… но здесь возможны варианты:

1. OFS смещает центр, по которому определяем какой процент микширования -proc или +proc применять для микширования + OFS это еще и точка центра для микширования
2. OFS просто смещает результат микширования отражающийся на получателе… процент микширования применяется по центру который задан в источнике жестко (OFS на него не влияет)

какой вариант берем ? второй ?

Написал вчера компрессор текстового вывода…
пока в словаре всего несколько слов :

; Коды слов из словаря

0x60 PPM
0x61 КАНАЛ
0x62 МОДЕЛ
0x63 НАСТРОЙК
0x64 ЗНАЧЕНИ

уже за счет них, за вычетом расходов на дополнительный код (который кстати за счет рекурсии получился буквально в 20 байт) и таблицу хранения токенов - получена экономия порядка 120 байт…

но сохранять слова полностью как это сделал я на самом деле не выгодно… обычно сохраняют буквенные последовательности… типа “НА”, “КА”, “КОЛ”, “МОД” - и уже из этих последовательностей получают слова… компрессия обычно достигает минимум 50% при полной работоспособности кода и без всяких раскодирований сжатого кода во время работы…
вот этот словарь и хочеться для русского языка найти…
сейчас у меня размер словаря 95 слов… можно увеличить еще где то на 60…

строки заданные словарями выглядят вот так:

U11_LCH_EDIT_CAPTION:    .DB        0 , 0 , 0x63, "И ЛОГ. ", 0x61, "ОВ   " , 0  , 0
                                    ; НАСТРОЙК        ;   КАНАЛ

; заголовок для редактора mn_edit_rec.asm
U11_LCH_EDIT_STR_CAP:    .DB     0 , 0 , "ЛОГИЧЕСКИЙ ", 0x61, " ", 0
                                                    ;  КАНАЛ
U11_LCH_EDIT_REV_STR:    .DB        "РЕВЕРС ", 0x61 ,"А  ", 0
                                        ;  КАНАЛ

Предложение: Добавить функцию (либо на кнопочку, либо на менюшку в настройках модели), которая бы пересчитывала текущие значения триммеров в соотвествующие значения сабтримов и суммировала их к уже существующим значениям, а триммера после этого сбрасывала в ноль. Т.е. технически эта функция должна пробежать по всем миксам пользователя, получая на вход отклонения стиков, равные соответствующим триммам, а на выходе значения для отклонения соответствующих серв, но сервы отклонять, конечно, не надо, а просто добавляем эти значения к сабтримам.

Дмитрий, не поверишь ! тоже ношусь с этой идеей ! хотел это сделать еще с VCoder’ом но тогда не додумал до конца модель пересчета…
здесь хочу сделать подобное вашему описанию

ПРО ФУНКЦИИ:

в прошивку закладываю возможность существования функций которые могут использоваться в сравнениях условий или в выражениях либо работать на прямую.
пока продуманы (соответственно с точки зрения как функционала так и входящих данных) следующий функции:

1. БОРТ. БАТ - это счетчик расхода батареи без обратной связи. в идеале эта функция возвращает остаток заряда батареи борта рассчитывая его по расходу канала Thro. Планирую получить около 5% точности - что думаю очень даже не плохо для тех кто не имеет телеметрии

2. Т ПОЛЕТА - прогноз оставшегося времени полета модели - функция исходя из расхода по каналу Thro за некоторый промежуток времени рассчитывает сколько еще времени можно налетать до заданного остатка в батареи…

3. P КОНТР. - контроль выходной мощности по каналу Thro - функция плавно ограничивает максимальный расход по каналу Thro через определенный промежуток времени. Думаю будет полезна тем у кого связка мотор+регулятор+батарея - в режиме максимальной мощности работают с небольшой перегрузкой и кому эту перегрузку необходимо ограничить во времени автоматически снизив расход по каналу Thro до определенной величины… (например у меня 40А мотор и регуль в максимале на 4S дают 42,5 А мощности… более 4-5 секунд - и мотор перегревается… - используя эту функцию я гарантирую снижение тока двигателя через 3 секунды до 39А вне зависимости от положения стика управления тягой)

У кого еще какие есть мысли про функции ? предложите - и я подумаю !

лучше озаботиться этим сейчас так как сейчас уже расход RAM порядка 80% и под новые фенички лучше зарезервировать место чтобы потом не придумывать как его высвобождать 😃

Так работают системы компрессии. Выбирается редко используемый символ, например Ц. Если в исходном тексте встречается этот символ, то он в коде заменяется на ЦЦ. Если встречаеются часто повторяемые слова и фразы они заменяются на Ц1, Ц2… Ца, Цб… … и т.д. Получается байт после Ц будет определять конкретную фразу.

Так работают системы компрессии. Выбирается редко используемый символ, например Ц. Если в исходном тексте встречается этот символ, то он в коде заменяется на ЦЦ. Если встречаеются часто повторяемые слова и фразы они заменяются на Ц1, Ц2… Ца, Цб… … и т.д. Получается байт после Ц будет определять конкретную фразу.

Неее, это слишком накладный способ… у меня проще 😃
всего около 32 символов и цифр, 32 латинские большие буквы, 32 русские большие буквы… остальные коды свободные…

вот начиная с кода символа 0x60 и до 0x9F я выделил словарную зону…
соответственно просто ставлю нужный мне код и получаю сразу печать токена… (помнишь как было у ZX Spectrum?)

p.s. в словаре 9 понятий - экономия на строковых константах на текущий момент около 450 байт !! (сам не ожидал что так эффективно будет)

КСТАТИ, редактор микшеров еще никто не смотрел или он на самом деле никого не напугал ? 😉

Дмитрий, не поверишь ! тоже ношусь с этой идеей ! хотел это сделать еще с VCoder’ом но тогда не додумал до конца модель пересчета…
здесь хочу сделать подобное вашему описанию

Дак, собственно, что там думать… У нас есть набор каналов, и набор функций, которые формируют значения на этих каналах. Подаем на вход этих всех функций все наши триммы, получаем сабтриммы. Это фактически то, что делает аппа 50 раз в секунду (или сколько там точно) во время управления моделью.
Единственная здесь загвоздка, которую я вижу - это условные функции, но супер-гемороем то заниматься(делать триммирование под все возможные условия) ни кто не заставляет, каждый должен понимать, что модель триммируется под один конкретный режим (один набор условий), как правило прямолинейный полет без всякой выпущеной механизации. Соответственно на мой взгляд интуитивнее всего, да и проще, сделать чтоб функция брала текущие значения для всех условий.
Как я вижу применение такой функции:

1. Оттриммировал самолет, сел.
2. Если у меня есть условия на миксах, зависящие от РУДа, то отключил двигатель.
3. Установил все тумблеры в режим обычного полета, все стики в нейтраль, газ в положение, при котором триммировал(в этом пункте слово все означает все, на которых висят условия. Т.е. если от движка ничего не зависит, то и по боку положение РУДа).
4. Жмакнул кнопочку с функцией.
   В простейшем случае ее можно жмакнуть даже прям в полете, т.к. практически она на него не повлияет.

Написал вчера компрессор текстового вывода…
пока в словаре всего несколько слов :
…

U11_LCH_EDIT_CAPTION:    .DB        0 , 0 , 0x63, "И ЛОГ. ", 0x61, "ОВ   " , 0  , 0
                                    ; НАСТРОЙК        ;   КАНАЛ

; заголовок для редактора mn_edit_rec.asm
U11_LCH_EDIT_STR_CAP:    .DB     0 , 0 , "ЛОГИЧЕСКИЙ ", 0x61, " ", 0
                                                    ;  КАНАЛ
U11_LCH_EDIT_REV_STR:    .DB        "РЕВЕРС ", 0x61 ,"А  ", 0
                                        ;  КАНАЛ

Честно говоря не уловил, что вы пытаетесь пожать, сам текст программы или программу (результат компилляции) ?
Если первое, то зачем, вы его храните внутри памяти аппы? 😃
Если второе, то помоему при таком коде сборку делает только асм(компиллятор), и после сборки у вас в области данных будут собранные слова(занимающие полный объем).
Я конечно не бог весть какой знаток асма (только для оптимизации С-шных функций пользовал, внутри С-ного же компиллятора), но чтоб собирать слова нужно использовать отдельную функцию, типа strcat к примеру. Хотя strcat каждый раз будет искать конец первой строки, а это процессорное время. Если у вас все длинны строк заранее известны, то оптимальнее просто strcpy.
На мой взгляд оптимальным решением было бы выделить некий буфер длинной в максимальную длинну используемых строчек, и каждый раз в нем вручную собирать строчки, после сборки выводить содержимое на экран. Это реально пожмет область данных (правда в ущерб области кода, т.к. вызов функции с параметрами - это как минимум адрес функции и все ее параметры).
На C код бы выглядел примерно так(используя словарь из вашего примера):

char StrBuf[50]; //50 - к примеру
strcpy(&StrBuf, 0x63, 8);
strcpy(&StrBuf+8, "И ЛОГ.", 6); //8 - длина текста в 0х63 (НАСТРОЙК)
strcpy(&StrBuf+14, 0x61, 5);
strcpy(&StrBuf+19, "ОВ ", 4); //3+1 "/0"

print(StrBuf)

Хотя пока писал код уже сам понял, что тут апсолютно ничего не экономится, потомучто вызов подобной функции это минимум пяток байт в области кода, итого +20 байт +9 байт на добавочных фразах, которые вне словаря, а сэкономить то пытались на фразе НАСТРОЙКИ ЛОГ.КАНАЛОВ - длиной в 21 байт 😃
В общем, резать и собирать то, что и без того не длинно - идея так себе 😃 Не заморачивали бы вы себе этим голову.
Единственное полезное, что приходит на ум - найти в компилляторе галочку, что-то типа “искать одинаковые строки”, тогда можно не бояться писать прямо в коде кучями одинаковые строки - после компилляции на их местах будет один и тот же адрес, и соответственно фраза в памяти данных будет один раз, но это все равно не относится к отдельным словам внутри фраз.

ПРО ФУНКЦИИ:

У кого еще какие есть мысли про функции ? предложите - и я подумаю !

Может я не очень внимательно изучал мануал и возможности прошивки. 😵
Хотелось бы иметь функцию отключения (перевода в режим минимального положения) канала газа при включении аппаратуры.На большой электричке случайное включение аппаратуры с не нулевым выходом канала газа может привести к травмам. Даже если установить фильтр, то не факт, что при включении тумблер управления будет в режиме отключения двигателя. Поэтому хотелось бы иметь функцию, которая не позволяла бы включаться аппаратуре при нахождении выключателя двигателя (положении стика газа) при котором возможен неконтролируемый старт мотора.

какой вариант берем ? второй ?

Я за второй вариант. Дело в том, что все наши разговоры касаются только симметричных линейных функций. И смещение функции надо делать вертикально на пост. величину. Кому это неудобно - пусть рисуют абсолютно произвольные кривые в редакторе.
Первый вариант создает излом кривой. Я уже рисовал, что к элеронам он категорически не подходит из-за разных величин отклонений вверх и вниз.

Итак, должно быть следующее. ИМХО конечено.

1. ВВодим понятие суб-триммера. Это постоянная величина смещения на выходе каждого канала.
2. В каждом микшере добавляем смещение ОФС. ОФС смещает фунцию по вертикали или иными словами прибавляет/отнимает к выходному сигналу постоянную величину.

Остаются понятие кривой и триммера. Мне очень интересно узнать где происходит их наложение.

Честно говоря не уловил, что вы пытаетесь пожать, сам текст программы или программу (результат компилляции) ?
Если первое, то зачем, вы его храните внутри памяти аппы? 😃
Если второе, то помоему при таком коде сборку делает только асм(компиллятор), и после сборки у вас в области данных будут собранные слова(занимающие полный объем).

Нее, не уловили…
прикол в том что после сборки уменьшается объем кода !
это и в теории и в практике 😃

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

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

тут апсолютно ничего не экономится, потомучто вызов подобной функции это минимум пяток байт в области кода, итого +20 байт +9 байт на добавочных фразах, которые вне словаря, а сэкономить то пытались на фразе НАСТРОЙКИ ЛОГ.КАНАЛОВ - длиной в 21 байт 😃
В общем, резать и собирать то, что и без того не длинно - идея так себе 😃 Не заморачивали бы вы себе этим голову.

Вы не поняли…
повторю:
есть словарь слов…
сейчас он вот такой:

LCD_TOKEN_TABLE: ; таблица размещения токенов
            .DB        low(FONT_TOKEN_PPM*2)            , high (FONT_TOKEN_PPM*2)        ; 0x60
            .DB        low(FONT_TOKEN_CHANNEL*2)        , high (FONT_TOKEN_CHANNEL*2)    ; 0x61
            .DB        low(FONT_TOKEN_MODEL*2)            , high (FONT_TOKEN_MODEL*2)        ; 0x62
            .DB        low(FONT_TOKEN_TUNE*2)            , high (FONT_TOKEN_TUNE*2)        ; 0x63
            .DB        low(FONT_TOKEN_VAL*2)            , high (FONT_TOKEN_VAL*2)        ; 0x64
            .DB        low(FONT_TOKEN_AIL*2)            , high (FONT_TOKEN_AIL*2)        ; 0x65
            .DB        low(FONT_TOKEN_EXPO*2)            , high (FONT_TOKEN_EXPO*2)        ; 0x66
            .DB        low(FONT_TOKEN_RATE*2)            , high (FONT_TOKEN_RATE*2)        ; 0x67
            .DB        low(FONT_TOKEN_SW*2)            , high (FONT_TOKEN_SW*2)        ; 0x68



FONT_TOKEN_PPM:        .DB "PPM"    , 0
FONT_TOKEN_CHANNEL: .DB "КАНАЛ"    , 0
FONT_TOKEN_MODEL:     .DB "МОДЕЛ"    , 0
FONT_TOKEN_TUNE:    .DB "НАСТРОЙК", 0 , 0
FONT_TOKEN_VAL:        .DB "ЗНАЧЕНИ", 0
FONT_TOKEN_AIL:        .DB "ЭЛЕРОН", 0 , 0
FONT_TOKEN_EXPO:    .DB "ЭКСПОНЕНТА", 0 , 0
FONT_TOKEN_RATE:    .DB "РАСХОД", 0 , 0
FONT_TOKEN_SW:        .DB "ПЕРЕКЛЮЧАТЕЛЬ", 0

далее в строке которую нам нужно выводить со словарем вместо словарных значений мы просто используем номер токена
например для слова НАСТРОЙКА наш код должен быть таким
.DB 0x63 , “A”, 0 , 0
где,
0x63 - это слова НАСТРОЙК
“A” - это буковка А (все вместе получается НАСТРОЙКА"
ну и два завершающих нуля - первый конец строки, второй выравнивание…

то есть для первого слова настройка мы теряем: 5 байт - 2 байта завершающих нулей в словаре + 2 байта на адрес строки токена в таблице токенов (она как раз выше словаря) + 1 байт-код токена в нашей печатаемой строке…
длина слова НАСТРОЙК - 8 байт…
то есть напечатав так второе слово НАСТРОЙКА мы уже экономим 3 байта !!! третий раз 11 байт… !!! - обратите внимание 0x63 в строке печати автоматом выведут токен НАСТРОЙК… и потом просто добавьте А - для НАСТРОЙКА, или И - для НАСТРОЙКИ… 😃

тоже самое со словом КАНАЛ (-А, -ОВ, -ОМ) экономия на одном слове не такая большая… вот только слово КАНАЛ у меня встречается более 15 раз !! это минимум 70 байт экономии…

и так далее…

но сам словарь у меня слабый… я как то очень давно (лет 8 назад!) находил словарь из буквенных токенов… вот там действительно компрессия была!! текст объемом в килобайт сжимался в среднем байт до 300… эхх… знал бы сохранил тот словарь… а тогда просто запомнил алгоритм и сейчас вот его реализовал…

кстати по коду получается примерно такое
есть процедура печати строки LCD_WRSF - она печатает строку пока не встретит завершающий ноль, либо пока не напечатает 25 символов (это размер строки) - последнее ограничение введено для отладки - чтобы при ошибках в адресах строк не пытаться напечатать больше чем нужно…
процедура LCD_WRSF в своей работе вызывает процедуру LCD_CHAR - это как раз процедура печати символа…
в процедуре LCD_CHAR я проверяю код символа - дело в том что я не храню образы всех 256 символов - я ведь использую только символы, цифры, и большие буквы русские и латинские - поэтому у меня две таблицы - 1: латиница + цифры, и 2:русские буквы
одна начинается с 0x20 (Как всегда с пробела)
вторая с 0xC0
они реально небольшие первая 64 символа* 5 байт = 320 байт + вторая 32 символа **5 байт = 96 байт. ИТОГО на весь знакогенератор потрачено 416 байт вместо 256*5 = 1280 байт…
соответвенно коды символов с 0x60 по 0x9F я использую для токенов…
когда нахожу токен то просто рекурсивно вызываю LCD_WRSF с адресом печати ТОКЕНА который получил из таблицы адресов токенов…
код реализующий это выделен в коде - можете сами оценить его размер (сам не ожидал что получиться так кратко)

;==============================================================================================
;                                                                                Печать символа
.include "lcd_font2.asm" - это знакогенератор и таблица токенов с токенами

LCD_CHAR:
            ; печатаемый символ в temp
            ; режим печати в temp2
            PUSH    temp3
            PUSH    temp2
            PUSH    temp1
            PUSH    temp
            PUSH    ZH
            PUSH    ZL
            PUSH    YH
            PUSH    YL

            SUBI    temp    , 0x20                ; вычтем из кода символа код пробела

            CPI        temp    , 0x40                ; код символа в латинской группе символов?
            BRSH    LCD_CHAR_M2_1                    ;  нет, переходим к анализу дальше !

            ; загружаем таблицу с латинскими буквами
            LDI     ZH        , high(LCD_FONT_20*2)
            LDI     ZL        , low(LCD_FONT_20*2)
            RJMP    LCD_CHAR_M3                 ; идем на расчет символа

; КОД ДЛЯ ОРГАНИЗАЦИИ СЛОВАРНОЙ ПЕЧАТИ !!!!!! -------------------------------------------
LCD_CHAR_M2_1:
            CPI        temp    , 0xA0                ; код символа в русской группе символов ?
            BRSH    LCD_CHAR_M2        ; переходим на русские буквы

            SUBI    temp    , 0x40    ; вычтем из кода символа код первого спец. символа
            LDI        ZL        , low (LCD_TOKEN_TABLE*2)
            LDI        ZH        , high(LCD_TOKEN_TABLE*2)
            LDI        temp1    , 2
            MUL        temp    , temp1
            ADD        ZL        , R0
            ADC        ZH        , R1
            ; в ZH адрес адреса в таблице :-)
            LPM        YL        , Z+
            LPM        YH        , Z
            PUSH    YH
            POP        ZH
            PUSH    YL
            POP        ZL
            CALL    LCD_WRSF ; просто рекурсивно печатаем строку токена!

            RJMP    LCD_CHAR_EXIT            ; идем на выход
;----------------------------------------------------------------------------------------
LCD_CHAR_M2: ; загружаем таблицу с русскими буквами
            SUBI    TEMP    , 0xA0              ; вычтем из кода символа код русской "А"
            LDI     ZH        , high(LCD_FONT_C0*2)
            LDI     ZL        , low(LCD_FONT_C0*2)

LCD_CHAR_M3: ; рассчитаем адрес символа в таблице
; дальше код печати одного символа

Я за второй вариант. Дело в том, что все наши разговоры касаются только симметричных линейных функций. И смещение функции надо делать вертикально на пост. величину. Кому это неудобно - пусть рисуют абсолютно произвольные кривые в редакторе.

ОК, для меня второй вариант тоже проще !! да и прав ты наверное Вячеслав, так проще даже объяснять кому либо !!!

Итак, должно быть следующее. ИМХО конечено.

1. ВВодим понятие суб-триммера. Это постоянная величина смещения на выходе каждого канала.

а субтримом мы не можем считать центр канала ?
или под субтримом ты понимаешь величину смещения всех точек канала ? ничего что минимальное (или максимальное) значение канала может выйти за пределы?
в принципе канальный импульс за разрешенные пределы не выйдет - есть процедура контролирующая общую допустимость пакета (поэтому тут можно не беспокоиться- обрежет молча по максимуму и все 😃
но вот что делать с заданными пользователем пределами min\max ?

2. В каждом микшере добавляем смещение ОФС. ОФС смещает фунцию по вертикали или иными словами прибавляет/отнимает к выходному сигналу постоянную величину.

по поводу OFS я понял - на величину OFS смещаем результат микширования !! все… баста… причем соответственно OFS не влияет на расчет границ или центров каналов при микшировании… - так ? - с этим тоже понял… (надеюсь что правильно)

Остаются понятие кривой и триммера. Мне очень интересно узнать где происходит их наложение.

По триммерам - триммер накладываю на значение органа управления сразу после его получения с органа управления… (немного маслянного масла…)
по коду примерно так

CALL UCH_READ
CALL TRIM_MERGE

соответственно дальше везде !! идут значения UCH с уже наложенными тримерами !! соответственно UCH_MIDLE может не совпадать после триммирования с центром полученным после наложения…

по кривой - как договорились ранее в микшере обработка будет следующая

1. получили значение источника микширования (посмотрите по коду что это может быть)
2. наложили на источник микширования кривую - получили скорректированное значения источника микширования
3. микшируем источник на получатель с использованием процента микширования “-” или “+” в зависимости от того какое значение источника мы получили после кривой
4. накладываем на получатель смещение OFS

далее, при формировании пакета если результирующий канал выходит за пределы обрезаем его по возможному максимуму !!

так ?

может быть с учетом последнего сообщения в ветке про VCoder исправленные триммерами значения UCH использовать только в микшерах ? а в остальных использовать чистое значение UCH ? (но блин не понятно где это вылезет… нужно подумать!)

Суб-триммер применяется для начального выставления центральных положений рулей. Включили модель, каждый руль вывели на ноль суб-триммером (если сделать это механически нет возможности) и ВСЕ! В дальнейшем, величина суб-триммера постоянно присутствует в выходном канале неизменно. Все отклонения руля будут считаться от этой точки. Естественно, что величина канального импульса за дозволенные пределы выйти не может, должно быть ограничение сверху и снизу.

По своей сути, ОФС полностью аналогичен субтриму. Он так-же смещает выходной сигнал. Но, ОФС находится в микшере. И офс можно менять для разных полетных режимов. Иными словами ОФС задает начальное смещение рулевых поверхностей относительно субтриммированного центра. Например задав ОФС на элерон, мы получаем фиксированное отклонение - флаперон.

Про какой мин/мах идет речь?
Если это ограничение канального импульса - то однозначно за этот предел выходить нельзя. Если пользователь установил предел от 1200 до 1800 мкс, то в этих точках должно наступать ограничение независимо от установленных субтриммеров.
Если же пользователь ставит ограничение отклонения руля от +30% до -30%, то руль должен отклоняться на указанные величины относительно субтриммированной точки.

Если пользователь установил предел от 1200 до 1800 мкс, то в этих точках должно наступать ограничение независимо от установленных субтриммеров.

Совершенно согласен. Иначе смысл в мин/макс пропадает. Я эти величины именно по отзыву серв настраиваю, как и указано в мануале…

Если же пользователь ставит ограничение отклонения руля от +30% до -30%, то руль должен отклоняться на указанные величины относительно субтриммированной точки.

Согласен, только если первый абзац в сообщении будет верен.

Суб-триммер применяется для начального выставления центральных положений рулей. Включили модель, каждый руль вывели на ноль суб-триммером (если сделать это механически нет возможности) и ВСЕ! В дальнейшем, величина суб-триммера постоянно присутствует в выходном канале неизменно. Все отклонения руля будут считаться от этой точки. Естественно, что величина канального импульса за дозволенные пределы выйти не может, должно быть ограничение сверху и снизу.

В настройках каналов есть параметр - ЦЕНТР КАНАЛА - этот параметр является субтриммером ? включили модель и выставили центры каналов… в дальнейшем этот центр всегда центр 😃))) крайние точки тоже выставляются отдельно…

просто здесь есть 2 варианта:

1. ЦЕНТР КАНАЛА = СУБТРИМ - следовательно ничего мудрить и не нужно - все уже есть
2. СУБТРИМ меняет все 3 точки ! например изменяем нулевое положение поверхности на 100 мкс в сторону максимума - одновременно меняются на 100 мкс в сторону максимума и мин и макс значения канала - то есть диференциала элеронов при субтриммировании не будет ! (либо диференциал останется на том же уровне что и был)

может быть сделать такую модель:

на UCH накладывается триммер - который как бы отклоняет стик управления в ту или иную сторону…
ЦЕНТР КАНАЛА и крайние точки - задаем так как нам нужно с нужными нам углами отклонения…
СУБТРИММЕР - меняет положения всех 3х точек канала - для того чтобы не потерять углы отклонения плоскостей при изменении позиции центра канала…
при изменении значения СУБТРИММЕРА - могут измениться и расходы - но это изменение будет симметричным для обоих направлений, если уперлись значением макс. канала в лимит канального импульса- то на следующем шаге изменения следим чтобы (центр-мин)=(макс-центр) (это при случае если изначально диф. элеронов задан не был) - то есть чтобы расходы при субтриммировании оставались одинаковы для обоих направлений! пусть даже в ущемление самой величины расходов ! это нужно для того чтобы модель после субтримирования не стала расстроенной из за возникших диференциалов которых небыло при первоначальной настройке…

Пишется меню “ФУНКЦИИ - ПРОГНОЗЫ БОРТА” A-Coder.hex.html

можно задавать емкость батареи и токи двигателя по нескольким точкам для прогноза времени полета модели и остатка заряда батареи

в принципе это меня сейчас не самое важное просто на нем отрабатывается математическая библиотека (сейчас это умножение 16ти битных чисел, деление 8ми битных)

может быть сделать такую модель:…

ИМХО, было бы здорово. А оффсет тогда - аналог субтриммера, но применительно к каждому конкретному микшеру (т.е. тоже не будет вызывать дифференциала)?

ИМХО, было бы здорово. А оффсет тогда - аналог субтриммера, но применительно к каждому конкретному микшеру (т.е. тоже не будет вызывать дифференциала)?

А вот на счет этого давайте думать как лучше…

Вячеслав, что бум делать с OFS ?
в принципе OFS не будет вызывать дифференциала так как мы договорились выше что OFS это просто сдвиг результата микширования на получателе…
то есть изначально пропорции микширования берутся из заданных min\mid\max и процента микширования… а потом просто к результату прибавляем OFS (линейно!)

Вячеслав, я правильно пишу ?

Виталий, чем будете запускать таймер в режиме тренер-ученик?

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

“просто здесь есть 2 варианта:”
По регулировкам я предпочитаю второй вариант. В первом кодере в этом плане очень неудобно было. Меняя центр, приходилость лезть в другое меню и менять крайние точки. Лучше при изменении центра сразу синхронно менять края.

(центр-мин)=(макс-центр) Вот этого я бы делать не стал. Пользователя мы совсем запутаем. Субтриммер выставляет нулевую точку, а за величину расходов у нас отвечают только микшера. И не надо одно мешать с другим.

Все должно быть просто. Собрали модель. Выставили нулевые положения рулей субтримом. Далее вертим стики и регулируем расходы. Если получается мало или много - пользователь сам решает как изменить микшер или переустановить крайние точки в канале.

Субтрим применяется только на этапе постройки модели. Он, как и расходы канала, выставляется один раз. Установили ноль и забыли.
А ОФС, в этом плане, работает при настройке в полете. Если надо в полетном режиме получать фиксированное отклонение поверхности от нуля - выставляем ОФС.
ОФС линейно прибавляется к выходу микшера.

Виталий, чем будете запускать таймер в режиме тренер-ученик?

таймеры (Все) будут иметь несколько входящих\выходящих событий… поэтому запуска в классическом виде от кнопки или от стика не будет…

в прошивке будет 5 таймеров… один из них (1) будет иметь предел счета чч:мм:сс… остальные будут наверное только мм:сс… все таймеры могут работать независимо друг от друга в различных направлениях, с разными стартовыми значениями, условиями работы, событиями

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

таймер отслеживает условия:

1. Условие старта таймера - при его однократном возникновении начинается счет (повторное возникновение условия при уже работающем таймере ничего не меняют - счет продолжается)

2. Условие останова таймера - при его однократном возникновении счет останавливается (повторное возникновение условия при уже остановленном таймере ничего не меняют - таймер стоит)

3. Условие счета таймера - при выполнении условия таймер считает (условие применяется в качестве альтернативы условиям 1 и 2)

у таймера есть события

1. Счет - истинно когда таймер включен

2. Останов - истинно когда таймер остановлен

3. Счет закончен - достижение нуля или максимального значения таймера (99:59 для минутных и 99:99:59 для часового таймера)

Какие условия можно формировать вы можете посмотреть в тестовой версии прошивки A-Coder.hex, меню: “Редактирование модели - Расширенная настройк - Условия\Выражения”

вот такие вот дела будут с таймерами

“просто здесь есть 2 варианта:”
По регулировкам я предпочитаю второй вариант. В первом кодере в этом плане очень неудобно было. Меняя центр, приходилость лезть в другое меню и менять крайние точки. Лучше при изменении центра сразу синхронно менять края.

В принципе тоже думал об этом… но пока не реализовал…

(центр-мин)=(макс-центр) Вот этого я бы делать не стал. Пользователя мы совсем запутаем. Субтриммер выставляет нулевую точку, а за величину расходов у нас отвечают только микшера. И не надо одно мешать с другим.

Просто микшер всегда растягивает диапазоны…
рассмотрим пример
min = 1000 мкс
mid = 1250 мкс
max = 2000 мкс
(я специально беру гипертрофированные значения mid чтобы было понятно)
тогда значение микширования -50% будет равно 1250-(1250-1000)*50%=1125 мкс -> расход от центра 125 мкс
а значение микширования +50% будет равно 1250+(2000-1250)*50%=1625 мкс -> расход от центра 375 мкс

поэтому и возникло мое предложение чтобы субтриммер в отличие от центра канала двигал еще и крайние точки таким образом чтобы соотношение расходов сохранялось !

ЦЕНТР КАНАЛА - этот параметр является субтриммером ?

Да.

есть 2 варианта:

Мне удобнее 1-й вариант. Но если есть возможность, можно оставить право выбора за пользователем и он сам сможет переключить например на СУБТРИМ меняет все 3 точки
Вот только это:

при изменении значения СУБТРИММЕРА - могут измениться и расходы - но это изменение будет симметричным для обоих направлений, если уперлись значением макс. канала в лимит канального импульса- то на следующем шаге изменения следим чтобы (центр-мин)=(макс-центр) (это при случае если изначально диф. элеронов задан не был) - то есть чтобы расходы при субтриммировании оставались одинаковы для обоих направлений!

Мне непонравилось. Например в результате настройки имею отклонение от нулевого положения + 20 и -30 градусов. Сдвигаю субтриммер. Получу +15 и -15? Так?
Второй пример: было +30 и -30 град. значительно сдвигаю субтрим. Что получим? +5 и -5 ??? Мне так не хотелось бы. Гораздо лучше, когда останется +5 и -55. Неестественное отклонение? Да! На то она наладка. Позже можно поменять длину тяги и сохранить нужные углы.

тогда значение микширования -50% будет равно
расход от центра 125 мкс
расход от центра 375 мкс

Можно поправить Вашим способом или самостоятельно уменьшить расход в одну из сторон.

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

Субтрим применяется только на этапе постройки модели. Он, как и расходы канала, выставляется один раз. Установили ноль и забыли.
А ОФС, в этом плане, работает при настройке в полете. Если надо в полетном режиме получать фиксированное отклонение поверхности от нуля - выставляем ОФС.
ОФС линейно прибавляется к выходу микшера.

Здесь (кроме жирного) не соглашусь. Выставили субтрим. Нам кажется, что в ноль. Запускаем модель. Она требует сделать трим вверх. Делаем. Величина триммера начинает участвовать в микшере. А мне нужно, что бы эта величина отсутствовала. Сажаем модель. Убираем триммер и чуть добавляем субтрим. Снова запускаем, смотрим…
Тоже, но с офсетом - выставляю офсет для настройки микшера по моему усмотрению. Запустил, меняю офсет до горизонтального полета. Опять микшер изменился…
Единственный путь не вносить изменения - субтрим (центр канала без обработки).

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

Мне непонравилось. Например в результате настройки имею отклонение от нулевого положения + 20 и -30 градусов. Сдвигаю субтриммер. Получу +15 и -15? Так?
Второй пример: было +30 и -30 град. значительно сдвигаю субтрим. Что получим? +5 и -5 ??? Мне так не хотелось бы. Гораздо лучше, когда останется +5 и -55. Неестественное отклонение? Да! На то она наладка. Позже можно поменять длину тяги и сохранить нужные углы.

Помоему мы не совсем поняли друг друга…
тот функционал что предлагаю я подразумевает возможности изменения и центра канала (пожалуйста меняйте только его и пусть остается +5 и -55)… так и изменения всех трех точек одновременно (сейчас мы это называем субтримом)…

Или, как вариант, при рассчете субтрима проверять условие: если участки min-mid и mid-max равны, то менять все 3 точки разом. Если отличаются - то менять только центр. Ну и оставить возможность произвольной настройки конечных точек (которая, судя по всему, и так планировалась). Думаю, так получится угодить и вашим и нашим.
Да, и еще неплохо было бы настройку центра и конечных точек сделать на одном экране. Что-то типа настройки центра в первом кодере, только справа и слева от значения центральной точки расположить значения крайних точек и сделать их доступными для редактирования. Что-то вроде такого:
№ канала min mid max
1 1000 1500 2000
2 900 1450 2100
По умолчанию выделять имеено средний столбец (центр канала), а при необходимости задать конечные точки, смещать курсор кнопками +/-.

Или, как вариант, при рассчете субтрима проверять условие: если участки min-mid и mid-max равны, то менять все 3 точки разом. Если отличаются - то менять только центр. Ну и оставить возможность произвольной настройки конечных точек (которая, судя по всему, и так планировалась). Думаю, так получится угодить и вашим и нашим.

Лучше я сделаю изменение сразу 3х точек…
а одну точку менять можно если менять центр…
помоему это логично

Да, и еще неплохо было бы настройку центра и конечных точек сделать на одном экране. Что-то типа настройки центра в первом кодере, только справа и слева от значения центральной точки расположить значения крайних точек и сделать их доступными для редактирования. Что-то вроде такого:
№ канала min mid max
1 1000 1500 2000
2 900 1450 2100
По умолчанию выделять имеено средний столбец (центр канала), а при необходимости задать конечные точки, смещать курсор кнопками +/-.

Это уже сейчас сделано… выглядит правда немного по другому… но все точки настраиваются в одном месте !

Это уже сейчас сделано… выглядит правда немного по другому… но все точки настраиваются в одном месте !

Ну, тогда вопросов больше не имею. Отдельной настройки min-mid-max и субтрима, меняющего сразу все 3 точки будет достаточно. ИМХО.

1. По поводу словаря, честно сказать, я так и не понял, но раз утверждаете, что работает, то не вижу повода не верить 😃
   Прокомментировал бы только вот эту вашу фразу:

но сам словарь у меня слабый… я как то очень давно (лет 8 назад!) находил словарь из буквенных токенов… вот там действительно компрессия была!! текст объемом в килобайт сжимался в среднем байт до 300… эхх… знал бы сохранил тот словарь… а тогда просто запомнил алгоритм и сейчас вот его реализовал…

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

2. По поводу триммеров (проскакивало по тексту). Триммер всегда должен влиять на крайние точки расходов, иначе если двигать только нулевую точку, мы нарушим пропорциональность отклонения рулей. Единственное, что тут стоит оговорить: расходы конечных каналов(что подается на сервы) и расходы результатов микширования для этих каналов - должны быть(как бы это выразиться? 😃 ) разными ячейками памяти, т.е. это разные понятия. Триммер должен контроллировать центровку результатов микширования(т.е. он должен смещать как mid, так и min, max, но именно микса). А расходы канала должны накладываться на расходы конечного микса для этого канала, и на пропорциональность хода влиять не должны, их цель - только защитить рули модели от выламывания путем сильно большого отклонения мощной сервой и по идее они задаются в самом начале настройки модели, еще на земле, и в дальнейшем не трогаются.

3. По поводу OFS. Что-то вы жестокое мутите 😃 Применить его в качестве триммирования выхода миксов - идея не плохая… Но почему бы не глянуть, как сделано это же самое OFS в какой-нибудь футабе?

4. Возникла еще идея по поводу функционала миксов: может быть можно сделать так, чтобы процент микширования можно было изменять динамически в зависимости от значений каналов? Т.е. сейчас он задается жестко в настройках, и в принципе, учитывая наличие большого числа миксов, мою идею можно реализовать просто задействовав несколько миксов поочередно включаемых по мере движения стика, но это не совсем комильфо, т.к. будет ступенчатость, да и если что-то захочешь поправить, придется лазить во все эти миксы.
   К примеру, применить динамический микс можно в такой ситуации: всем известно, что при увеличении угла атаки уменьшается эффективность элеронов, а руль направления все больше начинает выполнять функции как раз элеронов. Имея динамический микс, значение которого зависело бы от РВ, я могу при сильном отклонении последнего управлять креном модели уже не только элеронами, но и помогая РН. Т.е. в прямом полете РН будеть, просто как РН, а в глубоких виражах он будет помогать элеронам. В общем может не самый востребованый пример, актуален больше на тяжелых свистках, а на пилотажке только помешает, но применения можно придумать тьму…

1. По поводу словаря, честно сказать, я так и не понял, но раз утверждаете, что работает, то не вижу повода не верить 😃
   Прокомментировал бы только вот эту вашу фразу:

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

По хорошему да… но для этого нужно будет опять писать программу которая будет анализировать текст… и она в принципе даст схожие с универсальным словарем результаты…
так или иначе пока я оставил так как есть… компрессия и так значительная… так что новые строки буду преобразовывать в значения словаря пока в ручную… потом может быть как нить сделаю автоматизацию этого процесса

2. По поводу триммеров (проскакивало по тексту). Триммер всегда должен влиять на крайние точки расходов, иначе если двигать только нулевую точку, мы нарушим пропорциональность отклонения рулей.

Нет. не правильно… триммер это фактически отклонение ручки управления ! и ничего больше !!
тянет самоль вниз - триммером фактически прижимаем ручку чуть на себя… ни о каких других точках в триммере речи нет и не может быть!

3. По поводу OFS. Что-то вы жестокое мутите 😃 Применить его в качестве триммирования выхода миксов - идея не плохая… Но почему бы не глянуть, как сделано это же самое OFS в какой-нибудь футабе?

Гм… так вроде на футабе именно так и сделано… Вячеслав кидал скан мануала… да и сам мануал где приведены примеры этого

4. Возникла еще идея по поводу функционала миксов: может быть можно сделать так, чтобы процент микширования можно было изменять динамически в зависимости от значений каналов? Т.е. сейчас он задается жестко в настройках, и в принципе, учитывая наличие большого числа миксов, мою идею можно реализовать просто задействовав несколько миксов поочередно включаемых по мере движения стика, но это не совсем комильфо, т.к. будет ступенчатость, да и если что-то захочешь поправить, придется лазить во все эти миксы.
   К примеру, применить динамический микс можно в такой ситуации: всем известно, что при увеличении угла атаки уменьшается эффективность элеронов, а руль направления все больше начинает выполнять функции как раз элеронов. Имея динамический микс, значение которого зависело бы от РВ, я могу при сильном отклонении последнего управлять креном модели уже не только элеронами, но и помогая РН. Т.е. в прямом полете РН будеть, просто как РН, а в глубоких виражах он будет помогать элеронам. В общем может не самый востребованый пример, актуален больше на тяжелых свистках, а на пилотажке только помешает, но применения можно придумать тьму…

То что вы пишите называется регулируемый микс… он есть в VCodere…

Нет. не правильно… триммер это фактически отклонение ручки управления ! и ничего больше !!
тянет самоль вниз - триммером фактически прижимаем ручку чуть на себя… ни о каких других точках в триммере речи нет и не может быть!

Извиняюсь, оговорился, речь шла про сабтрим. С триммером вопросов нет, это просто смещение стика.

Виталий, с днюхой!!! 😃

Поздравляю!!!

Спасибо большое !!

Редактор таймеров A-Coder.hex.html

ну наверное теперь пора переходить уже к реализации функционала…
попробую сегодня написать чтение ADC и калибровку…
кстати по калибровке у кого нить есть какие нить пожелания ?

В старой версии калибровка сделана вполне приемлемо.

Чем проще и интуитивно понятнее - тем лучше. Можно с графикой аналоговых органов? Или это лишнее?

Народ, а для стиков нам точно нужна 10-ти битная точность или все таки 8-ми битной было бы достаточно ?
А то сейчас читал доки по АЦП меги - там есть возможность делать 10-ти и 8-ми битные режимы чтения состояния крутилок
В соседнем разделе уже ктото дважды жаловался на то что есть эффект дрожания стика - думаю это как раз из за разрядности АЦП и “шумности” всей аппарутуры в целом…

А надо сделать возможность выбора! Или разрешение оставить 10 бит, но и чтобы возможность интеграции по времени была. В конце концов, на входы АЦП тривиально вешаются интегрируюшие конденсаторы, и дрожь уже меньше…

помоему в прошивке Thus была возможность снижать битность АЦП… как раз помоему максимум на 2 бита…

А надо сделать возможность выбора! Или разрешение оставить 10 бит, но и чтобы возможность интеграции по времени была. В конце концов, на входы АЦП тривиально вешаются интегрируюшие конденсаторы, и дрожь уже меньше…

гм… возможность выбора… это сильно… просто еще и проще вычисления были бы если 8 бит…

ладно… буду думать…

А нет ли каких нибудь несложных алгоритмов шумоподавленя?
Может ето выход?

Не надо алгоритмов. Емкость на входе задавит шумы, и опорное для АЦП тоже надо отфильтровать. Не знаю, есть ли у процессора нога для этого. Кажется, есть. Существуют ещё прецизионные генераторы опорного напряжения… Дорогие, правда… И питанию надо уделить особое внимание, и резисторы стиков питать от отдельного стаба… И т.д. и т.п.

Во первых. Емкости и прециз опорники шумов АЦП не устраняют. В поцессоре стоит АЦП интегрирующего типа. На входе АЦП аппаратно реализовано УВХ (уст-во выборки хранения). Прецизионное питание может повысить только точность и стабильность (уход нулевых точек от температуры и т.п.) преобразования.
Во вторых. Переход на 8 бит проблемму дрожания не решает. Последний бит по любому дрожать будет. Конечно меньше чем при 10 битах, но весовое значение бита здесь в 4 раза больше - а это гораздо хуже.
Однозначно. преобразование надо делать 10 разрядным. В дальнейшем, можно и цифровой усреднитель на последний бит поставить. Хотя и это ни к чему. При 10 битах дрожание младшего бита не превысит 2 мкс в выходном сигнале. Такую точность ни одна машинка не отрабатывает.

Теперь про дрожание. Я уже писал на форуме, как доработать пищалку в аппаратуре. В момент “писка” ток она жрет 150 мА. От этого все напряжения питания просто “с ума сходят”. Отсюда и дрожание стиков. Решается проблемма одним резистором.

В общем вчера эксперементировал 😃
Вот что пока получилось A-Coder.hex

Кстати на практике 8ми битного режима думаю было бы более чем достаточно… попробуйте сами !

В итоге сделал возможность выбора пользователем 8ми или 10ти битный режим АЦП использовать…
Меню:НАСТРОЙКА ПЕРЕДАТЧИКА - ОРГАНЫ УПРАВЛЕНИЯ
ПРОСМОТР КАЛИБРОВКИ - просмотр установленных калибровочных значений
КАЛИБРОВКА - калибровка стиков (еще не написал графическую индикацию положения стиков, сама калибровка “в слепую” уже работает)
РАСКЛАДКА СТИКОВ - это как раз про наши 4 моды 😃
РАЗРЕШЕНИЕ АЦП - выбор 8 БИТ / 10 БИТ
ПРОСМОТР ЗНАЧЕНИЙ АЦП - просмотр текущих значений АЦП с учетом выбранного разрешения АЦП

Значения калибровки сохраняются только при выборе НАСТРОЙКА ПЕРЕДАТЧИКА - СОХРАНИТЬ НАСТРОЙКИ (так же как и все другие настройки)… не сохраненные - будут потеряны при выключении…
Все настройки сохраняются в FLASH (EEPROM пока не использовал, планируется что он уйдет под модели по максимуму)

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

На наш 60ти градусный ход стика разрешения в 200 итераций более чем достаточно… попробуйте прошивку что выложена в предыдущем сообщении…
кстати я 2 дня лопатил кучу форумов на предмет шумов АЦП - многие авторы вообще пишут что в меге нормально отрабатываются только старшие 8 бит АDC… а младшие шумят сами по себе…
в нашем железе, у меня на 2ух аппаратурах, достаточно стабильно работают 10ти битные выборки (и в VCoder’e и в A-Coder’e)
но тем не менее - как я уже писал - и в личке у меня есть одно обращение, и на ветке дневника про VCoder - что есть дрожание по одному из каналов АЦП
Думаю теперь эти люди попробуют и отпишутся если что… благо что ничего дополнительно для них писать не нужно будет- перевел режим в 8 бит, сделал калибровку и можно пробовать

Однозначно. преобразование надо делать 10 разрядным. В дальнейшем, можно и цифровой усреднитель на последний бит поставить. Хотя и это ни к чему. При 10 битах дрожание младшего бита не превысит 2 мкс в выходном сигнале. Такую точность ни одна машинка не отрабатывает.

Цифровой усреднитель боюсь не поможет - слишком уж коротко время выборки 😦
я сейчас использовал максимально возможное значение предделителя - 128, и то получается что на частоте 16 мгц - это почти 200 000 выборок в секунду…
пока не заморачиваюсь скоростной оптимизацией, но дальше наверное все таки перепишу код таким образом чтобы было только 8 выборок каждые 20 мс и не более (чтобы не грузить процессор всякой фигней)

Теперь про дрожание. Я уже писал на форуме, как доработать пищалку в аппаратуре. В момент “писка” ток она жрет 150 мА. От этого все напряжения питания просто “с ума сходят”. Отсюда и дрожание стиков. Решается проблемма одним резистором.

Нее, пищалка это другая проблема… и скорее кривых шнурков - насколько я помню из осцилограмм которые снимали и выкладывали в ветке про VCoder - там просто портится сам импульс… причем не значительно… - а стремные (читайте дешевые) шнурки этот шум умудряются обработать как короткие импульсы…

А при чем здесь время выборки?
Сам же пишешь - 8 выборок за 20 мс. Большей скорости и не требуется. Складываешь все 8 значений, а потом сумму делишь на 8 (сдвиг вправо на 3 бита). Вот тебе и среднее значение сигнала. Если там есть шум то он устранится этим усреднением.

как причем ?
если шум который мы получаем из АЦП от внешнего сигнала - то чтобы избавиться от него наверняка необходимо: как можно больше выборок за как можно большое время… вот как раз со вторым и проблемы…

В принципе на 2х моих аппах 10ти битные значения АЦП читаются нормально… думаю у многих ситуация похожая (иначе бы форум уже завалили сообщениями об этом)… поэтому пока усреднять значения не буду…

Калибровка аналоговых каналов, графика, A-Coder.hex.html

Описание меню
Подменю “НАСТРОЙКА ПЕРЕДАТЧИКА” - “ОРГАНЫ УПРАВЛЕНИЯ”:

ПРОСМОТР КАЛИБРОВКИ - просмотр действующих калибровочных значений органов управления

КАЛИБРОВКА - калибровка органов управления (подробнее о процессе калибровке ниже)

РАСКЛАДКА СТИКОВ - изменение раскладки стиков на 4-ре моды

РАЗРЕШЕНИЕ АЦП - выбор разрешающей способности АЦП (8\10 бит)

ПРОСМОТР ЗНАЧЕНИЙ АЦП - просмотр текущих значений с каналов АЦП. можно проверить на дребезг и диапазоны значений

В принципе осталось сделать маленький штрих по инициализации калибровки (а то при выборе 8ми битного режима АЦП после калиброванного 10ти битного не получим калибровку максимальных значений - это не есть правильно)

Пока процедура калибровки следующая - двигаем каждый орган управления вверх-вниз до конца… потом останавливаемся в середине и жмем EXIT… (да, да, знаю, переделаю чтобы по EXIT просто был выход а по MENU сохранение результатов калибровки)

p.s. вчера до часу ночи мучался с целочисленными операциями… сейчас уже могу делить 16ти битные числа (умножение 16ти битных делал ранее)… на очереди 32ух битные (ими как раз буду оперировать при расчете длительностей канальных импульсов)

Итоговая прошивка с калибровкой A-Coder.hex.html

Гляньте…
теперь во время калибровки по EXIT выход из калибровки без сохранения результата, а по MENU c сохранением
ну и плюс написал учет значений калибровки при 8ми и 10ти битном режиме…

В общем гляньте, если замечаний не будет то в таком варианте блок останется и для финальной версии прошивки

Алексей, если не затруднит, попробуйте тестовую прошивку A-Coder.hex

Попробовал. Дрожания значений АЦП не замечено ни в десятибитном, ни в восьмибитном режиме (+/- единичка не в счет - это именно стик встает на граничное значение). Все органы управления работают адекватно, значения калибровки при переключении режимов пересчитываются, сохранение настроек, вроде бы, работает. Жаль, генерации PPM пока нет - проверить бы, будет ли дрожание рулей на модели…
Да, и еще, может, все же стоит поменять кнопки + и - местами? А то как-то не логично увеличивать значение стрелкой влево. Точнее, непривычно после первой версии.

p.s. По редактору условий и выражений точно надо будет подробную инструкцию…

Попробовал. Дрожания значений АЦП не замечено ни в десятибитном, ни в восьмибитном режиме (+/- единичка не в счет - это именно стик встает на граничное значение). Все органы управления работают адекватно, значения калибровки при переключении режимов пересчитываются, сохранение настроек, вроде бы, работает.

Гм… у меня вообще никаких ±1 нет!!! ни в 10ти ни в 8ми битном режиме… значения встают четко и не меняются в любом положении !!

Да, и еще, может, все же стоит поменять кнопки + и - местами? А то как-то не логично увеличивать значение стрелкой влево. Точнее, непривычно после первой версии.

В первой версии все таки кнопки не соответствуют действию…
я посмотрю может быть перепишу так чтобы действия настраивались, в принципе у меня +\- всегда только изменение значений - это в первой версии они еще отвечают за выбор значения для изменения…

p.s. По редактору условий и выражений точно надо будет подробную инструкцию…

А что показалось не понятным на первый взгляд ?

вы можете создавать любые условия…
например, если нужно чтобы таймер начал считать при щелчке кнопки Trn
пишем условие номер 1

ОПЕРАЦИЯ ==
ТИП АРГУМЕНТ1 ОРГ. УПР
​ ЗНАЧ. АРГУМЕНТ1 TRN
​ ТИП АРГУМЕНТ2 ЛОГИКА
​ ЗНАЧ. АРГУМЕНТ2 ИСТИНА
​

То есть если записать в строку то получиться
“ЕСЛИ ОРГАН УПРАВЛЕНИЯ TRN==ИСТИНА”
ИСТИНА - это выключатель включен, ЛОЖЬ - выключатель выключен
Результат условия тоже либо ИСТИНА либо ЛОЖЬ !
При истине действие в котором предусмотрено условие выполняется…
согласитесь это просто !
идем дальше !

Теперь в меню ТАЙМЕРЫ
Выбираем например первый таймер и задаем

ТАЙМЕР ВКЛ
УСЛОВИЕ СТАРТА 01
​ УСЛОВИЕ ОСТАНОВА –
​ УСЛОВИЕ СЧЕТА –
НАПРАВЛЕНИЕ СЧЕТА +1
​ ТАЙМЕР: ЧАСЫ 00
​ ТАЙМЕР: МИНУТЫ 00
​ ТАЙМЕР: СЕКУНДЫ 00
​

Все!! ваш таймер стартующий по кнопке TRN готов !

Теперь вопрос на сообразительность - как заставить таймер 2 идти когда работает двигатель чтобы считать время работы двигателя ?

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

Теперь ответ
Создаем условие номер 2

ОПЕРАЦИЯ >
ТИП АРГУМЕНТ1 ОРГ. УПР
​ ЗНАЧ. АРГУМЕНТ1 ТЯГА
​ ТИП АРГУМЕНТ2 ФИКСИР.
ЗНАЧ. АРГУМЕНТ2 005%
​

если словами
“ЕСЛИ ОРГАН УПРАВЛЕНИЯ ТЯГА > 005%” - то есть если стик тяги отклонен более чем на 5%

Ну и теперь делаем таймер 2

ТАЙМЕР ВКЛ
УСЛОВИЕ СТАРТА –
​ УСЛОВИЕ ОСТАНОВА –
​ УСЛОВИЕ СЧЕТА 02
НАПРАВЛЕНИЕ СЧЕТА +1
​ ТАЙМЕР: ЧАСЫ 00
​ ТАЙМЕР: МИНУТЫ 00
​ ТАЙМЕР: СЕКУНДЫ 00
​

Ну как задачка ? мое и ваше решение совпали ?
в принципе условие 2 можно написать и по другому:

ОПЕРАЦИЯ >
ТИП АРГУМЕНТ1 ЛОГ. КАН
​ ЗНАЧ. АРГУМЕНТ1 03
​ ТИП АРГУМЕНТ2 ФИКСИР.
ЗНАЧ. АРГУМЕНТ2 005%
​

“ЕСЛИ ЛОГИЧЕСКИЙ КАНАЛ 3 > 5%” - ну если конечно на 3ем канале у вас двигатель

Причем заметьте что таймеров у вас 5 !! и еще 3 можете задействовать еще как хотите ! (например замерять время парения без двигателя !! условие уже поняли как задать ?)

и кстати, даже после этого у вас еще осталось 2 таймера ! 😃

p.s. надеюсь что после выхода этой прошивки вопросы “а вот добавить бы еще такой таймер…” просто исчезнут и перейдут в более веселый разряд: “а как настроить таймер…” 😃))

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

Насчет кнопок +/- однозначно надо менять. Правая кнопка всегда должна увеличивать, левая уменьшать. Надо сразу сделать и забыть. Даже у всех альтернативщиков так выполнено.

Кстати, в какой-то прошивке видел смену значений(и выбор вариантов) поворотом крутилки - ацки удобно.

Кстати, в какой-то прошивке видел смену значений(и выбор вариантов) поворотом крутилки - ацки удобно.

er9x

Гм… у меня вообще никаких ±1 нет!!! ни в 10ти ни в 8ми битном режиме… значения встают четко и не меняются в любом положении !!

Это проблема именно механики стиков в моем конкретном случае. При движении стика в + или в -, обратно они возвращаются не совсем точно в центр, а с разбросом в 2-3 единицы (при десятибитном кодировании). Иногда встают так, что АЦП не может определиться со значением и возникает “дрожаение” младшего знака. Но, т.к. машинки такое изменение импульса все равно не отрабатывают, я на это забил.

А что показалось не понятным на первый взгляд ?

вы можете создавать любые условия…
например, если нужно чтобы таймер начал считать при щелчке кнопки Trn
пишем условие номер 1…

Во-о-от! Именно это и надо! Какой пункт за что отвечает и пару примеров. Теперь все понятно, спасибо.

И еще, вопрос по типам передатчиков. Первый тип, я понимаю, штатный FlySky\Turnigy и прочие восьмиканальные модули без лишних наворотов. Второй - телеметрийные FrSky (с возможностью отображения данных на дисплее передатчика). А третий тогда что? LRS 433MHz Chainlink\Dragonlink, 12 каналов? Если да, было бы здорово…

Кстати, в какой-то прошивке видел смену значений(и выбор вариантов) поворотом крутилки - ацки удобно.

Гм…а какую крутилку используют - лицевую ?

в принципе смену цифровых значений с пределом от -120 до +120 действительно можно сделать на крутилку - посмотрю как это можно сделать малой кровью…

по кнопкам +\- - тоже посмотрю можно ли обойтись малой кровью чтобы добавить настройку их режима

Вчера было не очень много времени поэтому доработок минимум…
из видимых - добавил настройки триммерочиталки (время паузы между чтениями и задерживаться ли в нуле)… ну и заодно сделал так чтобы эти настройки сохранялись во Flash
A-Coder.hex.html

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

Угу… именно так… фактически были написаны все основные формы… а вот теперь “наша служба и опасна и трудна” - пишу пишу - но видно не много…

Гм…а какую крутилку используют лицевую ?

да

Доработка 1: Реверс кнопок +\-
A-Coder.hex.html

В меню НАСТРОЙКА ПЕРЕДАТЧИКА - НАСТРОЙКА КНОПОК МЕНЮ
РЕВЕРС КНОПОК +\- (ВЫКЛ\ВКЛ)
обращаю внимание что из за реверса пункт управляется только кнопкой “+” !! городить из за этого огород не считаю необходимым больше такого нигде нет 😃

после смены это значение как и все настройки будет сохранено в передатчике только после принудительного сохранения НАСТРОЙКИ ПЕРЕДАТЧИКА - СОХРАНИТЬ НАСТРОЙКИ

вроде бы работает везде правильно (то есть при нажатии на “+” - уменьшает значение (при реверсе) и при нажатии на “-” - увеличивает)
но если где просмотрел - скажите поправлю !!

(хотя по идее везде должно корректно работать я же в движке меню поправил)

Доработка 2: изменение значений крутилкой PIT TRIM
A-Coder.hex.html

Пока только для меню НАСТРОЙКА ПЕРЕДАТЧИКА, еще работает в РАСШИРЕННОЙ НАСТРОЙКИ МОДЕЛИ в простых параметрах… ну и еще по мелочи… в стандартной настройке моделей глючит (вернее не правильно работает - еще не правил)
Чтобы крутилка начала работать нужно через меню НАСТРОЙКА ПЕРЕДАТЧИКА - ОРГАНЫ УПРАВЛЕНИЯ откалибровать как минимум эту крутилку (завершение по MENU!!)
потом в меню НАСТРОЙКА ПЕРЕДАТЧИКА - НАСТРОЙКА КНОПОК МЕНЮ в пункте ЗНАЧЕНИЕ С PIT.TRIM поставить ВКЛ. (включить)…

Еще один “промежуток” для тестирования: A-Coder.hex.html

Объединил модули изменения параметров меню для стандартной настройки и настроек передатчика… экономия составила около 300 байт ! и это с увеличением функционала (регулировка параметров крутилкой)

правда сам еще не тестил, на работе собирал, дома вечером буду тестировать сам или можете это сделать сами…

на очереди добавления редактирования параметров в меню расширенные настройки… дело в том что если простые параметры (количество ppm каналов, пауза при опросе триммеров, яркость экрана и т.д.) меняются движком mn_menu.asm (и соответственно в нем только поправил и все сразу заработало)… то изменения в модулях редактирования например Значений, Условий и выражений, микшеров, органов управления и т.д. делаются модулем mn_edit_rec - соответственно нужно теперь прописать этот функционал в нем…
основная сложность в том что данный модуль фактически только движек меню по параметрам из таблиц… для изменения (Увеличения\уменьшения) параметров он вызывает соответствующие процедуры персональные для каждого параметра (в отличие от модуля mn_menu.asm в котором все параметры сведены в единую таблицу по которой просто выбираем макс. и мин. значения параметров)… придется еще додумывать как прикрутить туда крутилку чтобы не сильно гемороиться… тем более что модулей уже достаточно много - а много дописывать или переписывать каждый модуль как то не айс…

гм. может быть переписать модуль mn_edit_rec на табличную работу как с mn_menu ? но там очень много параметров меняет границы своих значений в зависимости от других параметров… 😦 то есть придется еще и на лету править таблицу мин.\макс. значений параметров 😦

Это проблема именно механики стиков в моем конкретном случае. При движении стика в + или в -, обратно они возвращаются не совсем точно в центр, а с разбросом в 2-3 единицы (при десятибитном кодировании).

Гм… да, проблема механики… а при 8ми битном режиме ? попадания в центр есть ?

И еще, вопрос по типам передатчиков. Первый тип, я понимаю, штатный FlySky\Turnigy и прочие восьмиканальные модули без лишних наворотов. Второй - телеметрийные FrSky (с возможностью отображения данных на дисплее передатчика). А третий тогда что? LRS 433MHz Chainlink\Dragonlink, 12 каналов? Если да, было бы здорово…

Нет… все проще.
по типу передатчика будут определятся длительности канальных импульсов…
например,
тип 1: мин=1000, середина=1500, макс=2000, полярность положительная
тип2: мин=1100, середина=1500, макс=1900, полярность отрицательная
и т.д.
может понадобиться тем кто использует например иногда модуль Spektrum а иногда штатный, или еще какой нить особо мощный модуль (bverc что ли он назывался ? на 1 вт который…) ну и опять таки некоторые шнурки требуют другой полярности сигнала (негативного) и уменьшенные до 1100-1900 диапазоны изменения канальных импульсов… теперь чтобы не настраивать отдельную модель, можно будет просто поставить тип передатчика “Шнурок USB” и не париться

А на счет количества каналов решение у меня уже есть в голове, еще с VCoder’a… осталось только его реализовать, для чего мне тут денежку скидывают на кошелек и я куплю себе отладочную плату для экспериментов.
в результате должно получиться устройство которое будет подключаться в один из каналов приемника и делать из одного канала 4… таким образом с одного 8ми канального приемника можно будет снять 4 быстродействующих канала (для управления рулями и тягой, стандартное быстродействие 50 обновлений\сек) и до 20 медленных каналов (обновляющихся не 50 раз\сек а где то 10 раз\сек, и с разрешением каждого из полученных каналов не более 200-400 итераций) - для подключения любых устройств…
количество итераций достаточное для очень многих задач… могу сказать что хоббикинговские железные микшеры V-крыла или хвоста тоже на выходе имеют всего 200 итераций - и ничего… народ с таким количеством итераций даже летает (то есть на управляющих поверхностях использует), я же предлагаю их использовать в менее ответственных задачах, а для управления именно полетом использовать 4-5 полнофункциональных канала

Гм… да, проблема механики… а при 8ми битном режиме ? попадания в центр есть ?

Да, попадает. Но там этой разницы положения стика просто не заметно (контроль положения более грубый).

Нет… все проще.
по типу передатчика будут определятся длительности канальных импульсов…
например,
тип 1: мин=1000, середина=1500, макс=2000, полярность положительная
тип2: мин=1100, середина=1500, макс=1900, полярность отрицательная
и т.д.

Понятно.

А на счет количества каналов решение у меня уже есть в голове, еще с VCoder’a…

Интересно, а как поведет себя дешифратор мультиплексированных каналов при срабатывании фейлсейфа или просто при пропадании сигнала?

При пропадании сигнала от приемника у дешифратора у самого фейлсейф сработает… так что все будет пучком 😃
аа, ну и при фейлсейфе приемника - дешифратор тоже включит фейлсейф…

Тестовая версия прошивки с возможностью изменения параметров крутилкой PIT TRIM
A-Coder.hex.html
Изменять крутилкой можно любое значение.

Сам еще не пробовал, буду пробовать вечером…

по идее пошел по наиболее простому пути… правда получилось что нужно затратить примерно по 30 байт на каждый уникальный параметр в модулях 😦 ну и на всех еще байт 40… все изменения потянули на байт 400-450…

Хорошо хоть очень многие параметры изначально писал как объекты - поэтому процентов 30 объектов получились уникальные с затратами на модификацию кода, а остальные процентов 70 - фактически использовали уже модифицированные первые 30 процентов и никаких модификаций не потребовали

В принципе уже вижу способ оптимизации размера - правда наверное с наскоку не получиться… нужно все таки покурить сначала что получилось сейчас… ну и кальян вечером заодно 😃

p.s. сейчас еще попросите сделать навигацию по меню при помощи крутилки ?

По поводу функционала крутилки при изменении значений:

во первых нужно откалибровать как минимум эту крутилку (PIT TRIM)- для этого идет в НАСТРОЙКА ПЕРЕДАТЧИКА - ОРГАНЫ УПРАВЛЕНИЯ - КАЛИБРОВКА
Далее крутим туда сюда пару раз, а лучше раза 3 чтобы надежно считались значения максимума и минимума, потом ставим крутилку в центр (и так с каждой крутилкой и каждым стиком)
потом жмем MENU
ВНИМАНИЕ ! если нажать EXIT - то калибровка отменяется ! не перепутайте…
После этого идем в меню НАСТРОЙКА ПЕРЕДАТЧИКА - НАСТРОЙКА КНОПОК МЕНЮ и ставим пункт ЗНАЧЕНИЕ С PIT TRIM в положение ВКЛ

ВНИМАНИЕ! все настройки передатчика в А-Coder не сохраняются по умолчанию, а сохраняются выбором пункта НАСТРОЙКА ПЕРЕДАТЧИКА - СОХРАНИТЬ НАСТРОЙКИ, с нажатием потом кнопки MENU

Изменять параметры можно и по старинке, кнопками +\-, а можно и крутилкой pit trim.
можно настроить значение грубо при помощи pit trim и уже потом подстроить точно при помощи кнопок +\-

ОБРАТИТЕ ВНИМАНИЕ ! пока вы крутилку не троните значение с нее считано не будет !
ОДНОВРЕМЕННО ! с крутилки считывается именно значение параметра, не происходит увеличение\уменьшение от текущего, берется значение !!!

У кого какие будут замечания\предложения ?

p.s. сейчас еще попросите сделать навигацию по меню при помощи крутилки ?

Не, стиком круче!
Шутка, конечно 😉

начинаю крутить новую версию.
С крутилкой пока все плохо. Если устанавливать длительность звука крутилкой то значение меняется след образом: 0-99-0-99-56. При этом в среднем нуле она пищит долго (как на 100). Примерно то-же и в других меню. Например в настройке триммеров.
Пункт “Реверс кнопок” по моим понятиям вообще лишний, но раз уж сделали то пусть по умолчанию будет включен.
Просмотр значений АЦП - стоит 10 разрядов и ничего не дергается. Максимум может менятся последняя единица. Полазил по меню калибровки, после этого значения АЦП начали показывать от 1000 до 5000. После выключения восстановилось. Повторить глюк пока не смог.
Если войти в калибровку и медленно опускать стик, то полоса индикатора рисуется до самого низа экрана, закрывая даже цифру.
При входе в калибровку предыдущие значения калибровки автоматически сбрасываются. Так делать категорически нельзя. Получается случайно зашел-вышел и крушение модели обеспечено на 100%. Обязательно должны быть подтверждения обнуления и перезаписи результата.

При наборе имени модели желательно включить автоповтор нажатой клавиши.

Наглядность и понятность меню надо улучшать. Если Виталий готов с этим поработать, буду писать предложения.

Исправления по крутилке A-Coder.hex.html

Остался глюк в меню НАСТРОЙКА МОДЕЛИ - РАСШИРЕННАЯ НАСТРОЙКА - ДОПОЛНИТЕЛЬНО

Долго мучался с отрицательными значениями в 8ми битном формате, сейчас работает но ценой невозможности редактирования значений максимум которых превышает 127, это не правильно, сегодня попробую добить окончательно крутилку

начинаю крутить новую версию.
С крутилкой пока все плохо. Если устанавливать длительность звука крутилкой то значение меняется след образом: 0-99-0-99-56. При этом в среднем нуле она пищит долго (как на 100). Примерно то-же и в других меню. Например в настройке триммеров.

Угу… выложенная вчера версия с крутилкой не была оттестирована (писал то на работе).
сейчас уже намного лучше… 😃 можете попробовать !

Просмотр значений АЦП - стоит 10 разрядов и ничего не дергается. Максимум может менятся последняя единица. Полазил по меню калибровки, после этого значения АЦП начали показывать от 1000 до 5000. После выключения восстановилось. Повторить глюк пока не смог.

У меня тоже бывает что ±1 значения меняются… нужно наверное это учесть в настройках. а то когда крутилка стоит на таком вот ±1 иногда не удается включить режим значения с pit trim - он включается, и тут же из за дребезга этой же крутилки выключается 😃)

по поводу 5000 - у меня такого ни разу небыло - было бы очень здорово если бы данный глюк обнаружился !! тоже буду смотреть (тем более что в связи с тестами функционала “значение с pit trim” я калибрую аппу каждый раз после заливки)

Если войти в калибровку и медленно опускать стик, то полоса индикатора рисуется до самого низа экрана, закрывая даже цифру.

Есть такое,
поправил,
еще и чуть поднял чтобы от индикатора до рамки снизу была полоса просвета в 1 пиксел 😃

При входе в калибровку предыдущие значения калибровки автоматически сбрасываются. Так делать категорически нельзя. Получается случайно зашел-вышел и крушение модели обеспечено на 100%. Обязательно должны быть подтверждения обнуления и перезаписи результата.

Если из меню “КАЛИБРОВКА” выйти кнопкой EXIT, то результаты калибровки не сохраняются…
хотя вы правы - лучше наверное написать подтверждение сохранения результата, так будет понятнее…

При наборе имени модели желательно включить автоповтор нажатой клавиши.

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

Наглядность и понятность меню надо улучшать. Если Виталий готов с этим поработать, буду писать предложения.

Надо !
Готов с этим работать !
Предложения очень нужны !
Тем более от тебя Вячеслав !! как не крути а ты мой самый ценный критик, больше то вообще никто ничего не пишет про “нравиться\не нравиться” - и это плохо, так как потом переписывать некоторые вещи очень сложно…
Так что спасибо за критику ! буду учитывать !

Сейчас есть кто живой ?

Версия для тестов: A-Coder.hex.html

ИЗМЕНЕНИЯ:

1. mn_uch_calibr.asm - Добавлено подтверждение завершения калибровки
2. mn_uch_calibr.asm - Изменен вывод индикаторов значений у калибруемых органов управления (внизу должен появиться один пиксел, плюс не должно быть выхода индикатора за рамки)
3. mn_menu_edit_new.asm - Отброшен младший бит значения UCH при редактировании значения крутилкой pit trim
4. mn_menu_edit_new.asm - введен 254 тип для редактирования крутилкой pit trim типов данных с отрицательными значениями (диапазон -120…+120), тип 255 - остается только за положительными значениями (диапазон 0…255)
5. переписаны модули uch_edit.asm, extval_edit.asm на предмет 254 типа (отрицательных значений)

ПРОВЕРИТЬ!

Правильность работы подтверждения после процесса калибровки
при нажатии на MENU (ДА) результаты должны сохраняться…
при нажатии на EXIT (НЕТ) результаты должны восстанавливаться из FLASH

Правильность отрисовки индикатора в процессе калибровки… индикатор НЕ ДОЛЖЕН ни при каких случаях выходить за рамки (обычно это в самом начале пока значения мин\макс не прочитаны)

Правильность считывания значения с крутилки pit trim - особенно:

1. простых значений (в том же меню настроек !)
2. Значений из меню ЗНАЧЕНИЙ, тип ФИКС, процентное значение должно крутилкой плавно меняться от -120…+120… причем на границах чтобы было именно -120 или +120 ! Тоже самое в меню ОРГАНЫ УПРАВЛЕНИЯ - границы каналов плавно от -120…+120… а вот задержки изменений каналов в меню ЛОГИЧЕСКИЕ КАНАЛЫ плавно от 0…255 !!!, при том что границы каналов и центр от -120…+120…
3. Значений токов двигателя из меню ДОПОЛНИТЕЛЬНО - ПРОГНОЗЫ БОРТА, должны меняться последовательно (с небольшим шагом) от минимума до максимума… кстати так же как и значения мощности батареи

Если кто сможет проверить СЕЙЧАС - было бы здорово - я бы возможно исправил еще какие нить мелочи и выложил новую версию для тестов (чтобы выходные не прошли просто так 😃

Сам я проверю только вечером… к сожалению скорее всего в выходные в интернете меня не будет 😦 и вообще не знаю займусь ли я в выходные прошивкой (уже расписаны выходные от субботы утра (поездка в Бузулук (250 км в одну сторону, и столько же в другую) и до воскресенья вечера включительно (с родственниками)

Версия для тестов: A-Coder.hex
​
Писал все выходные !

1. Еще раз переписана работа с числами при установке значений с pit trim - нашел очень удачное и простое решение - теперь корректно выставляются все значения и положительные и отрицательные. по всей видимости вопрос с установкой значения при помощи крутилки наконец то закрыт !

Попробовал работу с крутилкой в 8ми битном режиме - работает очень непредсказуемо на значениях диапазон которых превышает (либо рядом) диапазон крутилки (в 8ми битном режиме не более 256) поэтому при использовании 8ми битного режима АЦП крутилка как способ установки значений принудительно отключается !
Сам я очень долго тестировал установку значений крутилкой, нашел еще несколько связанных глюков, вроде бы их исправил. но допускаю что еще чтото может быть - так что если у кого будет возможность - попробуйте правильность работы этого функционала.

2. Найден застарелый глюк в mn_edit_rec.asm - если вы стоите на верхнем для изменения параметре и нажимаете кнопку UP то вместо перехода на последний параметр происходил сброс аппы… ошибка была найдена минут за 20… откуда она появилась сказать не могу… этот модуль переписывался частично где то в августе - может быть тогда “занес” потому что до августа этот модуль тестировал сам и в хвост и в гриву и модуль работал на 5 с плюсом…

3. Для тех кому нужен режим автоповтора в редакторе имени модели ввел в НАСТРОЙКИ ПЕРЕДАТЧИКА - НАСТРОЙКА КНОПОК МЕНЮ параметр:
   ПОВТОР В РЕДАКТОРЕ - выбираем ВКЛ если нужен повтор удерживаемой кнопки меню, и ВЫКЛ если повтор не нужен

4. Добавлен пункт ОБНОВЛЕНИЕ в значения.
   необходимо для того чтобы определять каким образом ЗНАЧЕНИЯ будут сбрасывать свои показания.
   сейчас 2 варианта:

5. ЗНАЧЕНИЕ в начале каждого обсчета модели сбрасывается в ноль

6. ЗНАЧЕНИЕ не сбрасывается автоматически, поэтому установившееся однажды значение параметра будет там до тех пор пока не измениться снова в процессе обсчета модели
   Теперь в модели будет возможность делать переходящие параметры. по задумке при помощи этой настройки мы сможем сделать постепенный инкремент\декремент значения при помощи например кнопки TRN…
   насколько я вижу этот функционал он очень нужен для использующих FPV так как от них идут запросы на функционал вида “нужно изменять значение канала последовательно на 100 мкс”… вот как раз при помощи данной настройки и нескольких условий можно будет сделать изменение значения канала на какую-то величину шага по кнопке TRN и например выключателем (пусть GEAR) указывать направление этого изменения (+\-)…

7. Добавлено меню ТРИМЕРЫ СТИКОВ
   Теперь у нас будет 5 наборов тримеров. каждый набор включается по условиям. в написанном меню вы как раз сможете назначать для каждого из наборов тримеров номер условия.

Еще чтото писал по мелочи… но если не помню значит не существенно 😃

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

Виталий! Откорой меню любой программы или просто щелкни правой кнопкой мыши. во всех окнах если строка содержит ссылку на другое меню, она помечается треугольничком.
Предлагаю разместить такие треугольники в самом правом знакоместе. Будет сразу ясно где переход в меню, а где изменение текущего параметра.
В качестве треугольника вполне подойдет знак “>”

“Насторойка передатчика”
Поскольку данные настройки проводятся единожды, то нет смысла в пункте “сохранить настройки”. Это лишняя и ненужная заморочка. Значения должны меняться и сохраняться “налету”.
Если нет в дальнейших планах, например сохранять разные настройки под разными именами, то данный пункт надо убрать.
В любом случае я не понимаю как можно отформатировть v-диск, а потом это сохранить или не сохранить. Такой путаницы нам не нужно.

Я с самого начала был против изменения разрядности АЦП. Механических и электирических проблемм самой аппаратуры это никак не решает. А вот непонятностей это доставит людям просто массу. Значения калибровки и значения АЦП при изменении разрядности показываются совершенно разные.
Я, конечно, это все понимаю, но как людям это потом растолковывать? Да и глюки уже полезли - режим “значение с PIT TRIM” в восьмибитном режиме включить невозможно.
Если душа жаждет борьбы с дрожанием АЦП этот пункт надо назвать “Фильтрация АЦП” и в дальнейшем воткнуть туда простейший фильтр/усреднитель.
Но еще лучше похоронить этот пункт и забыть!!!

Прикольно менять контрастность находясь в главном меню. Если мы начали тримом регулировать параметр, то этот параметр продолжает регулироваться даже если мы ушли совсем в другие экраны.

А вот “Просмотр значений АЦП” я бы дополнил. Ведь есть еще АЦП питания, может и еще какое (схема только на работе у меня есть). Плюс к этому сюда можно воткнуть состояния цифровых входов аппы в двоичном виде.
Вдруг какой триммер или тумблер глючить начнет? А тут зашел в окошко, понажимал кнопки и сразу все понятно стало.
Работоспособность кнопок глянуть можно. Сигнал на входе тренера возможно увидеть (ну и пусть он дергается). И т.д. Короче желательно все порты меги показать.

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

Виталий! Откорой меню любой программы или просто щелкни правой кнопкой мыши. во всех окнах если строка содержит ссылку на другое меню, она помечается треугольничком.
Предлагаю разместить такие треугольники в самом правом знакоместе. Будет сразу ясно где переход в меню, а где изменение текущего параметра.
В качестве треугольника вполне подойдет знак “>”

Написал, позже оттестирую на предмет захода знака “>” на текст пунктов меню

“Настройка передатчика”
Поскольку данные настройки проводятся единожды, то нет смысла в пункте “сохранить настройки”. Это лишняя и ненужная заморочка. Значения должны меняться и сохраняться “налету”.

сейчас все настройки передатчика сохраняются во FLASH (там же где и программа) - это позволило до сих пор, сохраняя уже более 60 байт настроек не затрачивать более ценный EEPROM…

Одновременно, не хотелось бы просто так переписывать FLASH… думаю что просто уделю этому больше внимания в доке по настройке передатчика…
да и пользователю думаю будет удобно - если что-то не то нажал и не помнит как было - то всегда есть вариант не сохраняя настроек выключить передатчик, потом включить и знать что ничего не изменилось

В любом случае я не понимаю как можно отформатировть v-диск, а потом это сохранить или не сохранить. Такой путаницы нам не нужно.

Про форматирование V и F диска будет отдельная песня 😃 форматирование диска с настройками пересекается только в определении размера кластера (да и то не решил еще делать это настраиваемой опцией или нет)
таким образом изменение настроек не будет влиять на диски, и форматирование дисков не будет влиять на настройки 😃

про диски: я еще все таки надеюсь на то что из FLASH-памяти останется килобайт 5-10 для организации FLASH диска… - таким образом под модели у нас будет минимум килобайт 5-10 !! а это даже при существующем увеличении описателя модели более 10 серьездных моделей (я ориентируюсь что на одну серьездную модель уйдет около килобайта)

Я с самого начала был против изменения разрядности АЦП. Механических и электрических проблем самой аппаратуры это никак не решает. А вот непонятностей это доставит людям просто массу. Значения калибровки и значения АЦП при изменении разрядности показываются совершенно разные.
Я, конечно, это все понимаю, но как людям это потом растолковывать? Да и глюки уже полезли - режим “значение с PIT TRIM” в восьмибитном режиме включить невозможно.
Если душа жаждет борьбы с дрожанием АЦП этот пункт надо назвать “Фильтрация АЦП” и в дальнейшем воткнуть туда простейший фильтр/усреднитель.
Но еще лучше похоронить этот пункт и забыть!!!

Оставим этот пункт как аварийный…

Разрядность конечно меняется, значения калибровки меняются - но с другой стороны для рядового пользователя (который не вникает в то как работает аппаратура “изнутри”) процедура калибровки в 8ми битном режиме будет выглядеть так же как и в 10ти битном: двинули стики по крайним положениям, поставили в центр, нажали “МЕНЮ”…
а какой режим стоит у АЦП это уже дело десятое… главное что управлять самолетом можно будет по прежнему… уверен что многие даже не заметят разницу в управлении (не всем нужна сверх точность, у многих еще аналоговые сервы стоят, да и цифровые не все блещут точностью)

Прикольно менять контрастность находясь в главном меню. Если мы начали тримом регулировать параметр, то этот параметр продолжает регулироваться даже если мы ушли совсем в другие экраны.

ОПС ! а вот это уже глюк !!!
самое обидное что ведь так можно и любой другой параметр менять… просто на контрасте LCD это заметно !!
сейчас буду смотреть как исправить !

Посмотрел !! да есть такое!
вроде поправил, дома попробую вечером !

А вот “Просмотр значений АЦП” я бы дополнил. Ведь есть еще АЦП питания, может и еще какое (схема только на работе у меня есть). Плюс к этому сюда можно воткнуть состояния цифровых входов аппы в двоичном виде.

Это все добавим со временем, пока есть чтение только АЦП каналов, поэтому их просмотр и добавил, как сделаю чтение выключателей - добавлю и их просмотр, и т.д.
на счет АЦП питания - просмотр будет в меню СИГНАЛИЗАЦИЯ БАТАРЕИ, тем более что само значение АЦП батареи нам все равно ничего не скажет, а вот калибровка значения батареи будет очень даже кстати !
ОО! там в 8ми битном режиме пляска будет 😃)))

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

СУПЕР !!
хоть какой то пункт без замечаний !!! 😃))

Закачал последнюю тестверсию А кодера. Все классно!!!
Все понятно с “нескольких тыков”, очень понравилась калибровка аналаговых органов. Очень просто и без лишних телодвижений. Правда уменя пока результаты калибровки не сохраняются. наверно не бописан код. На меню “расширенные настройки” потребуется расширенный же мануал. не знаю баг это или еще у Вас, Виталий, пока не дописано в коде, или у меня в железе что-то не так, но не регулируется время свечения экрана. Горит постоянно при любом значении “включение подсветки”.

ГМ… ну ту “последнюю” версию что вы закачали - Вячеслав чуть выше разбил в пух и прах (за что ему СПАСИБО, так как его замечания очень правильны с точки зрения привычности интерфейса, и его пользовательской удобности, да и глюки Вячеслав всегда находит такие каких я даже не видел) 😃))

Результаты калибровки применяются после подтверждения центров кнопкой МЕНЮ и второй раз МЕНЮ - подтверждаем результаты калибровки…
после этого стики и крутилки считаются откалиброваны…

НО если вы не выберете “СОХРАНИТЬ НАСТРОЙКИ” в меню “НАСТРОЙКИ ПЕРЕДАТЧИКА” - то результаты настроек, калибровка стиков и крутилок, и некоторые другие параметры после выключения аппаратуры не сохранятся !!! К сожалению я не могу во FLASH сохранять отдельные параметры настроек - либо все вместе, либо ничего… поэтому сделан отдельный пункт - как завершили все настройки - выбираем СОХРАНИТЬ НАСТРОЙКИ, и подтверждаем кнопкой МЕНЮ… после этого можно выключать аппу - при включении все настройки будут как до выключения

Подсветка пока не регулируется… в принципе часики тикают, значение есть - просто еще не делал (У меня в аппе нет подсветки, поэтому не писал и соответственно не тестил, займусь этим чуть позже)

У меня в аппе нет подсветки, поэтому не писал и соответственно не тестил

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

да нет… не нужно… я в сумерках не летаю 😃

Зря Вы Виталий отказываетесь. С подсветкой намного комфортнее не только летать, но и настраивать аппу. Кстати и у меня тоже лежит одна лишняя подсветка от Хоббикинга (новая, даже не подключал), могу подарить. Если черкнете адресок в личку, пересылка за мой счет.
Ждем дальнейших результатов в создании акодера. Удачи!

меня итак подарками в последнее время завалили ! пока давайте остановимся ! на новый год посмотрим 😃)))

Виталий. Интересно, а вообще реально сделать такую функцию , чтобы при включении на лубом канале серва автоматом крутилась то в одну сторону то в другую -100 … -50 … 0 … 50 … 100 … 50 …0 и так далие и скорость её работы можно была задавать.

Для чего? Да к примеру для такой функции

,прошу громко не смеяться =)

Версия для тестов A-Coder.hex.html

Сделаны маркеры подменю “>” в крайней правой позиции…
правда в меню расширенная настройка внутри подменю настройки параметров маркеров нет - зачастую там просто на него нет места (в микшерах, условиях) и поэтому не стал делать там зоопарк и поэтому во всех подменю меню расширенная настройка маркеров нет. да и переход в редактирование параметров там в каждой строке - нечего помечать как не переходящее внутрь 😃

Нашел пару глючков которые появились после внедрения изменения значения крутилкой (например в микшере иногда не редактировался процент микширования)

нашел причину почему включение режима ЗНАЧЕНИЕ С PIT TRIM срабатывало со второго раза (все остальное чудно работало с первого, а этот пункт только со второго !)

конечно исправил случаи когда удавалось редактировать параметр даже если уже вышел из меню 😃

еще что то по мелочи… ааа, в меню стандартная настройка указатель на подменю для таких пунктов как ДВ. РАСХОД ЭЛЕРОНОВ и подобных появиться только после того как режим будет в состоянии ВКЛ… в положении ВЫКЛ указателя на подменю не будет…

в общем протестируйте еще немного - чтобы потом уже не возвращаться назад…

Виталий. Интересно, а вообще реально сделать такую функцию , чтобы при включении на лубом канале серва автоматом крутилась то в одну сторону то в другую -100 … -50 … 0 … 50 … 100 … 50 …0 и так далие и скорость её работы можно была задавать.

Для чего? Да к примеру для такой функции ** ссылку на видео удалил ** ,прошу громко не смеяться =)

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

p.s. такое видео нужно в Аццкий РЦ Дизайн !! думаю что такого еще ни на одном самолете нет 😃) ну по крайней мере я не спец. по FPV - и для меня такой функционал стал откровением 😃

p.p.s. я громко не смеялся, но с утра улыбнуло ! 😃

спасибо =), ну вот я и первый тогда =)

Сергей Камоско Ай молодца! креатив! +100

Вчера добил 32ух битные умножение с деление… выкладывать прошивку не буду (все равно нигде не использую пока)
постараюсь до завтра написать расчет значений UCH в процентном соотношении… посмотрю наложение тримеров… в общем начинаю наполнять интерфейс жизнью 😃

Новая версия для тестов: A-Coder.hex

Сделал автокалибровку крайних значений аналоговых каналов, теперь можно сразу зайти в меню НАСТРОЙКА ПЕРЕДАТЧИКА - ОРГАНЫ УПРАВЛЕНИЯ - ПРОСМОТР КАЛИБРОВКИ и двигая стики увидеть как меняются крайние точки (средняя не изменяется, поэтому калибровка первоначальная все равно нужна !)

Заодно сделал первую версию целочисленного расчета значений органов управления (так же как и в VCoder задаем в меню НАСТРОЙКА МОДЕЛИ - РАСШИРЕННАЯ НАСТРОЙКА - ОРГАНЫ УПРАВЛЕНИЯ минимальное и максимальное значение органа управления и получаем на выходе процентное значение органа управления от мин. до макс.
к сожалению не все оказалось так просто, целочисленная арифметика преподнесла очередной сюрприз 😦 сегодня буду разбираться как пофиксить…
посмотреть значения органов управления можно в меню НАСТРОЙКА ПЕРЕДАТЧИКА - ОРГАНЫ УПРАВЛЕНИЯ - ПРОСМОТР ЗНАЧЕНИЙ АЦП, я там сделал доп. столбец… 😃

Для тех кому интересно что за проблема:
ДАНО:
у нас есть значения АЦП:
минимум органа управления - 0
максимум органа управления - 963
текущее значение - 500
​
Настройки органа управления:
минимум значения органа управления = -100%
максимум значения органа управления = +100%

ЗАДАЧА: НАЙТИ ЗНАЧЕНИЕ ОРГАНА УПРАВЛЕНИЯ В %

РЕШЕНИЕ

рассчитываем цену деления 963/(1+100-(-100)=963/201=4 - у нас челочисленная арифметика поэтому остатков нет !

теперь рассчитаем значение для текущего показания АЦП (по условию 500) -> 500/4+min=125+(-100)=25
вроде все красиво…

берем крайние значения:
Минимум АЦП (0):
0/4+min=0+(-100)=-100

а теперь берем максимум !
963/4+min=240+(-100)=140 !!! а максимум должен быть 100 ! 😃))

вот такая вот ботва…
с регулировкой pit trim я просто отсекал максимум… здесь так делать не хочу потому как нужно чтобы значение менялось пропорционально и постепенно на весь ход стика…

сегодня введу множитель четности - по идее должно помочь…

Для сохранения точности до 3-го знака после запятой можно ввести множитель степени 2-ки. Тогда цена деления будет 963*1024/201=4906. Текущее показание 500*1024/4906 - 100=104-100=4. Максимум 963*1024/4906 - 100=201-100=101. Что уже значительно лучше. Увеличивая степень двойки можно увеличить точность…
Да… тут 201 правильный ответ получается, т.к. цену деления искали для 201 участков. А надо было для 200.

гм… ну я думаю что на 1024 умножать не буду… думаю что 128 хватит… хотя конечно нужно пробовать…

Ну да… если шаг сетки 1%, то одной сотой разрешения должно хватать.

угу… шаг именно такой !
Для значений стиков больше не требуется…

а вся канальная математика считается напрямую, без всяких пересчетов на целые проценты - поэтому там точность не теряется… по крайней мере в VCoder’e не терялась… и здесь не думаю терять 😃

Если округлять промежуточные результаты в вычислении, то априори результат точным получить невозможо. Надо поставить правильный порядок вычислений с округлением конечного результата.
Для 0: 0*200/963+min= 0/963+(-100)=0-100=-100
Для 500: 500*200/963+min=100000/963+(-100)=103-100=3
Для 963: 963*200/963+min=192600/963+(-100)=200-100=100
Как видите все абсолютно точно!

Да, и обратите внимание. Я не случайно написал 200. Никакой лишней единицы в формуле быть недолжно!

По поводу сохранения настроек я не согласен. Вероятность изменить настройки и забыть что нажимал практически нулевая. А вот изменить настройки и забыть их сохранить это просто элементарно.
На практике, человек меняющий настройки передатчика всегда проверит как они работают. А если все работает, значит берем и запускаем модель. Вот и представьте чем это может обернуться.
Я лично знаю человека, который отказался от первой прошивки по причине автоматического несохранения значений триммеров. В процессе серьезных соревнований с жестким временным графиком действительно думать о таких мелочах просто некогда.

Как компромис: Сделай меню “сохранить настройки да/нет” при выходе из меню настроек в главное меню. Так хоть сохраниться не забудешь.

Присоединюсь к мнению Вячеслава. Было не раз, настроишь все “как у Кати” и… благополучно забудешь сохраниться на Vcoder. ИМХО Нужны промежуточные сохранения. Или при всяком изменении автоматические. А в микшерах лучше сделать сброс.

гм… ок… посмотрю на счет настройки режима автосохранения

Если округлять промежуточные результаты в вычислении, то априори результат точным получить невозможо. Надо поставить правильный порядок вычислений с округлением конечного результата.
Для 0: 0*200/963+min= 0/963+(-100)=0-100=-100
Для 500: 500*200/963+min=100000/963+(-100)=103-100=3
Для 963: 963*200/963+min=192600/963+(-100)=200-100=100
Как видите все абсолютно точно!

гм… сейчас посмотрю !

Если округлять промежуточные результаты в вычислении, то априори результат точным получить невозможо. Надо поставить правильный порядок вычислений с округлением конечного результата.
Для 0: 0*200/963+min= 0/963+(-100)=0-100=-100
Для 500: 500*200/963+min=100000/963+(-100)=103-100=3
Для 963: 963*200/963+min=192600/963+(-100)=200-100=100
Как видите все абсолютно точно!

гм… сейчас посмотрю !

Все именно так! Только сам бы я по-жадничал тратить кучку тактов на реальное умножение… а на сдвиг - не жалко 😃

угу… вот и я пожадничал… и сделал двумя делениями… и тоже думаю что лучше даже сдвиг делать не буду… а просто использую для деления DIV32 вместо DIV16… и младший байт делимого будет просто нулем… а второй и третий байт будут как раз 16-ти битным значением канала…

в общем сегодня если будет время по эксперементирую…

к сожалению прошедшие выходные “убил” на дешифратор MULTI канала для VCoder’а и A-Coder’ом вообще не занимался 😦

Здравствуйте, Виталий.

У меня есть еще одно пожелание по поводу функционала. Это касается кривых… Вы можете реализовать в новой прошивке при настройке кривых то, что бы точки для настройкb выбирались не кнопкой а самим стиком (или тем органом, который будем править… если это стик или крулилка…) и все это в режиме реального времени…

а теперь расскажу для чего это и почему прошу это реализовать…

Nное время назад решил 2-х моторник - тренер построить… т.к. была задумка в большой модели… решил начать с маленькой… его хоть не жалко будет угробить при возникновении внештатной ситуации… взял метроид и навесил ему 2 двигателя… короче захотелось новых впечатлений и естественно понять как можно больше моментов и по возможности отработать как можно больше внештатных ситуаций… отказ 1-го двигателя, малая разность оборотов, большая разность оборотов… и т.д. короче подготовиться и иметь хоть что-то типа навыков… дабы не сразу угробить большую модель…

движки взял с одной партии, но как Вы понимаете по разным причинам, коих, очень много, двигатели не могут работать на 100% одинаково… надо использовать кривую… почему кривую? А не триммеры… да потому, что триммер можно подогнать только в одном положении стика… а в другом будет разность оборотов в большую или меньшую сторону (проверено на железе! При настройке минимума… разность в максимуме на столько большая, что самолет…держа его за хвост… пытается развернуться в сторону по средствам большей тяги одного из двигателей)… вот по этому и нужна кривая… примерно точкам по 8-ми, а лучше больше точкам…

в варианте настройки кривой, что в V-CODER’e v. 0.99b я это осуществить не смог… т.к. не реально по сотни раз мереть разность вращений двигателей в одной и той же точке … потом заходить в кривые и там делать поправки… потом снова выходить и проверять… и т.д.

Надеюсь, что понятно описал просьбу…

если честно не понял что именно вас не устраивает 😦

вам нужны свободно назначаемые точки кривых ?
или нужно чтобы точка кривой (а их в VCoder’e - 9 штук) выбиралась при помощи стика ?

я так и не понял почему нужно мериться 100 раз разность скоростей вращения двигателя в одной и той же точке ?! достаточно измерить 1 раз…

Честно слово не понял какой функционал нужен и почему. 😦

Видимо требуется синхронизировать тягу движков на всем отрезке хода газа. Только я тоже не понял что именно товарищ предлагет реализовать. Видимо для этого нужно минимум два стика задействовать. Один на один двиг, другой - на другой. И в итоге добавляя газа первому, подстраиваясь вторым, и запоминая эти точки равенста тяги, можно выстроить равномерный отклик по тяге. Но это сущий гемор в плане программирования… Да и хорошо, если 2 движка, а если 4? а если 6? 😃
Возможный простой (для программирования) вариант решения, выводить просто значения стиков на экран (именно в цифрах, для точности), и по ним уже “химичить” свой нелинейный отклик на все движки(записав циферки на бумаге, и потом забив их в кривые откликов). Думаю того количеста точек, которое заложено в программе сейчас, вполне для этого будет достаточно.

Да, Дмитрий Варламов, правильно выразилься… нужна синхронизация движков…

первый двигатель (пусть будет 3-ий канал) работает от стика газа, а второй двигатель (скажем 5-ый канал) замикширован с третим и + поправки кривой (может и не кривой, а что другое) в большую или меньшую сторну…

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

и это все дело поправки… действительно нужны не в одной точке, а в многих по всему диапазону изменения сигнала от + к - или от - к +…

гм… обещаю подумать над этим…

Здравствуйте, Виталий.
Как дела с прошивкой?
Есть что новое на тестирование?
По поводу 2-х движков не думали?

По поводу 2х движков кстати реализуется при помощи назначения 2х кривых - без проблем настроил на маленький 2х моторник - разница в оборотах не больше 100 по тахометру - висит стабильно и никуда не тянет.

Поделишься настройками?

Скажу больше. Достаточно даже одной кривой. Т.е. один движек на линейном отклике, а второй на кривой, равной разнице Ваших двух кривых. Помоему все это очень не сложно. Вопрос только в отображении, для последующего анализа и сохранения, значений газа движков, при которых обороты равны. Дальше аппроксимируем по этим точкам и получаем свою конфетку.
Правда для ДВС это может потребоваться делать при каждом выходе на поле 😃 Т.к. постоянные перерегулировки практически неизбежны.
В железе передатчика, помоему, полностью сей процесс не автоматизируешь, т.к. требуется в каждый момент времени знать как положения стиков, так и показания тахометров(по которым и подгонять стики). А с участием человека с листочком и ручкой это вполне реально, причем из кодирования нужно только вывод цифр положения стиков на экран.
Т.е. к примеру, хотим получить отклик по 5 точкам(2 крайние, одна центровая, и две промежуточные):
На первый движек каждый раз накидываем 25% тяги, а второй подгоняем по оборотам и записываем значение на листочек. После теста создаем кривую для второго движка, в которую и забиваем значения с листочка.
Единственное, что тут можно сделать Виталию, это исключить бумагу “из оборота” 😃 Но ИМХО, это такие мелочи, что и не стоит напрягаться.

По поводу 2х движков кстати реализуется при помощи назначения 2х кривых - без проблем настроил на маленький 2х моторник - разница в оборотах не больше 100 по тахометру - висит стабильно и никуда не тянет.

На маленьком разница в оборотах совершенно не значительная и на нее можно “забить” а вот на движках к примеру 2212-10 попробуйте… Вы увидите… разница просто “ахтунг”…
Дабы было это наглядно, то на этих выходных сниму видео и сами посмотрите!

По поводу кривых и вычисления с листочком в цифрах… Может я конечно ничего и не понимаю, объясните мне как это можно сделать (вывести кривую) для второго мотора.

К примеру у нас диапазон сигнала от 500 микро секунд до 2500 микро секунд
начало вращения 1-го движка происходит на 750 микро секунд, а второй на 1100
соответственно на 1100 у первого двигателя уже будут бешеные (относительно) обороты,а второй только 200-400 т.к. он только завелся.
ВОПРОС:
Как с помощью прошивки первого варианта в определенном месте (в нашем случае 1100) занизить обороты первого двигателя до оборотов вращения второго?
В режиме реального времени я понимаю, а вот когда ни чего не крутиться и померить какие сейчас обороты ты не можешь… вот и приходиться по сто раз сохраняться запускать (опять же нужно четко попасть в определенную точку газа)… потом записывать опять идти в кривые… вносить поправки… сохранять проверять и т.д…

Намного проще было бы если выставил стик газа в то положение где начал вращаться 1-й двигатель (второй уже во всю крутится) и зная скорость вращения подкорректировал его… сохранил эту точку и перешел дальше… РАЗВЕ ТАК НЕ ЛУЧШЕ БЫЛО БЫ… ???..

Проект умер?

нет, просто сейчас доделываю параллельный (rcopen.com/blogs/50021/13016#comment13) на нем обкатаю генерацию ppm на ассемблере…

вообще конечно все больше и больши прихожу к мысли что очень убогая архитектура у турниги… сейчас в проекте по ссылке выше уже и связь с компом по ком порту, работа с симулятором по цифре, возможность перепрошивки без программатора… и все это на 16ой меге… в турниге же 64ая но из за архитектуры ничего толком не доступно 😦

Виталий, как там дела с прошивкой? Сейчай сижу на Вашей прошивке от 09,01,2011вроде всё устраивает, но хочется русский язык и можно ли будет тренерский разъём использовать для симулятора?

гм… тренерский разъем уже давно работает для симулятора…
с русским языком пока тяжко…

скоро по всей видимости будут подвижки, но не сейчас: я достаточно сильно занят пока 😦

Виталий, очень нужна прошивка VCoder2.
Дай БОГ тебе времени, терпения и сил на завершение проекта.