RSS лента

ВитГо

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

Рейтинг: 5.00. Голосов: 6.
07.09.2010 в 17:46 (43849 Показов)
ВНИМАНИЕ!!!

проект VCoder2 - обсуждение здесь
позже в этот дневник будут выкладываться ссылки на прошивку



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

В настоящее время пытаюсь обобщить текущие мысли по функционалу аппаратуры.

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

Новый функционал:

- предустановленные микшеры (летающее крыло, V-хвост, вертолетные миксы)

- захват до 8 каналов ppm с тренерского разъема - функция для тех кто иногда гоняет на шнурке учеников или использует хедтрекер или подобные устройства

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

- вычисляемые выражения для условий

- свободно назначаемые кривые и точки каналов


Максимум:

- увеличения размера VDISKа за счет Self Programming FLASH-memory до 10 кб (соответственно увеличение количества хранимых моделей до 30-60 шт)

Обновлено 29.12.2012 в 23:14 [ARG:5 UNDEFINED]

Категории
Без категории

Комментарии

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

    Поскольку аппаратура может быть использована с различными ВЧ модулями в функционал закладываю возможность задания 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... условий каждое из которых при установке в истину будет означать включение того или иного полетного режима (набора микшеров)

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

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

    В принципе можно сделать кривые и в микшерах и в канале (сначала обработаются первые, после всех микшеров вторые)
    Обновлено 07.09.2010 в 18:22 [ARG:5 UNDEFINED]
  2. Аватар для ВитГо
    Для обеспечения дополнительных возможностей условий - возможно задание простых выражений, с последующим использованием результата выражения в качестве одного из операндов условия..

    Это будут простые логические операции И, ИЛИ, НЕ, - с логическими значениями операнда
    Арифметические операции +, -, /, %, * - с процентными значениями операнда
  3. Аватар для ВитГо
    В принципе можно попробовать сделать вторую версию кодера открытым проектом - если конечно найдутся те кто пожелает участвовать в разразботке

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

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

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

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

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

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

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

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

    Timer3 - захват сигнала ppm, минимальный размер кода исполняемого в прерывании
  5. Аватар для HikeR
    Для включения\выключения микшеров будут использованы свободно назначаемые условия...
    (GEAR & THR.CUT)
    в примере показаны пара условий, а сколько планируется использовать выражений в условии? вот такое прокатит: (AIL_DR & !ELE_DR | !RUD_DR)?

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

    Вопрос возникает нужно ли у самого канала дополнительно иметь кривую ?
    или кривых при микшировании будет достаточно ?
    а я всегда думал, что кривая применяется самой первой к начальному значению полученного со стика/крутилки. при умножениях, возможно, ошибка и не накапливается, но при сдвиге значения вероятно будет нарастать очень быстро.
  6. Аватар для ВитГо
    Цитата Сообщение от HikeR
    в примере показаны пара условий, а сколько планируется использовать выражений в условии? вот такое прокатит: (AIL_DR & !ELE_DR | !RUD_DR)?
    Да, можно будет одним из операндов условия использовать результат другого условия
    соответственно будет конструкция из нескольких условий

    условие_1:
    !ELE_DR

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

    условие_3:
    !RUD_DR

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

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

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

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

    Цитата Сообщение от HikeR
    а я всегда думал, что кривая применяется самой первой к начальному значению полученного со стика/крутилки. при умножениях, возможно, ошибка и не накапливается, но при сдвиге значения вероятно будет нарастать очень быстро.
    гм.. кривая разве накладывается на орган управления ?!
    может лучше сделать кривую при микшировании и\или после всех вычислений на полученное значение канала (после наложения всех микшеров) этого будет достаточно ? (особенно интересует достаточность функционала для вертолетов, для самолетов таких извратов не нужно и достаточно кривую наложить на канал после всех микшеров)
  7. Аватар для ВитГо
    у меня описание условий пока в голове следующее:
    побайтно
    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 функции


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

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

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

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

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

    вид переменной
    00 - переменная не задана
    01 - фиксированное значение заданное в поле 01
    02 - значение органа управления, номер органа управления в поле 01
    03 - значение условия\выражения, номер условия\выражения в поле 01
    Обновлено 08.09.2010 в 17:41 [ARG:5 UNDEFINED]
  9. Аватар для ВитГо
    Микшеры

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

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

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

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

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

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

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

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

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

    результат будет разным. но если будет выбор, к чему именно применять кривую, то хуже наверное не будет.
  12. Аватар для ВитГо
    можно тогда ввести параметр на то когда применять кривую..
    0 - кривая применяется на значение органа управления
    1 - кривая применяется на результат микширования
    2 - кривая применяется к результирующему значению канала...

    так пойдет ?
  13. Аватар для ВитГо
    куда прицепить управление средней (нулевой) точкой канала ?

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

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

    недостаток двойных вариантов - расход памяти моделью.. соответственно будут заморочки с архивацией модели перед ее сохранением на V-Disk
  14. Аватар для druksel
    Виталь, наверно нужно таки сделать возможность при субтриммировании устанавливать и среднюю точку канала и крайние и это все на одной вкладке. может ошибаюсь на в предыдущей версии прошивки это было бы здорово.. а то там на одном экране - средние точки а на другом крайние. и этта.. думается что задание крайних и средних точек должно быть независимым.. то бишь сдвинул среднюю - а крайние остались так же. ну и по микшерам: неплохо бы добавить "готовые" микшеры типа - 2 машинки на РВ, 4 машинки на крыло - типа 2 элероны-2 флапы(щитки) и микшер типа элероны с РВ в противофазе (для уменьшения радиуса петли)
  15. Аватар для ВитГо
    просто установка крайних точек - это фактически учет физических ограничений серв и тяг подключенных к ним..
    а средняя точка - это уже настройка полетного режима... скорее всего и во второй версии это останется так же.. - правда мы еще не решили где это будет настраиваться... в микшерах или все таки в каналах... если в первых - то будет отдельное место (Как в первой версии) если во втором - то будет как вы желаете.. все 3 точки в каналах

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

    готовые микшеры будут ! главное не пропадайте когда я буду спрашивать какие нужны.. сейчас у меня есть набор желаемых микшеров для вертов (от Дмитрия HikeR), по самолетам соответственно летающее крыло, 2 сервы на элероны (флапероны)...
    в принципе главное движок написать для предустановленных микшеров, а потом накидаю сколько захотите..
  16. Аватар для druksel
    не. не пропаду.. а нсчет независимости при движухе точек.. хмм.. я тут начал среднюю точку двигать на 6 канале - и крайние поползли...
  17. Аватар для ВитГо
    такого не может быть Андрей,

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

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

    уточни - если я ошибаюсь - то нужно исправлять !!! скинь мне на мыло еепром !
  18. Аватар для druksel
    так.. вкладка LCH MIDDLE ползут. при изменении среднего значения.. прошивка не самая последняя , может поэтому??? ща солью епром и закачаю самую последнюю
  19. Аватар для druksel
    самую последнюю версию закатал.. тож самое.. :'(
    епром отправил через квип - включишь аську - получишь ссылку . куда то твой емейл у мну затерялсо..
  20. Аватар для ВитГо
    я тут комп поменял.. аську не помню..

    кинь на gorbukov@yandex.ru
  21. Аватар для ВитГо
    ураа!! я квип нашел нормальный!!

    мой номер в аське 600-989-219
  22. Аватар для druksel
    дико звиняюся - невольно дезинформировал народ - усе пашет нормально - эт я натупил
    Эти цифры показывают расстояние центральной точки от крайних . нужно для настройки дифференциала . а я то дурак подумал что это именно ползут точки
  23. Аватар для Stepan_M
    Виталий, я думаю полетные режимы всеже надо оставить - например для 3д и пилотажного режима так гораздо удобнее переключаться чем
    по условиям.

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

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

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

    Желаю творческих успехов. Как вернусь с отпуска буду готов тестировать.
  24. Аватар для ВитГо
    так фактически режимы и остануться..
    только это будут
    условие_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
    может быть по выбору либо другим режимом либо просто комбинацией отключающий предыдущий режим...

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

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

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

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

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

    а как удобно вам ?
    Обновлено 22.09.2010 в 11:34 [ARG:5 UNDEFINED]
  26. Аватар для druksel
    если чисто навигация по меню - то лучше второй вариант наверное. но желательно меню типа закольцевать по возможности
  27. Аватар для ВитГо
    да кольцо уже сделал :-)

    еще есть какие мнения...?
  28. Аватар для Stepan_M
    Виталий тут еще какое дело, при сохранении файла, на старой прошивке, если при этом включен приемник модели - то на время сохранения сервы загоняят в крайние позиции и что неприятно канал газа тоже. Был у меня несанкционированный взлет когда менял параметры на модели.
  29. Аватар для HikeR
    2. вариант стандартной прошивки - при удержании кнопки в течении какого то времени и потом ее отпускании - генерируется нажатие. повтора как такового при навигации по меню нет..
    по меню ходить одиночными нажатиями вполне допустимо, однако если придется вдруг где-то поменять значение -50 на +50 путем сотни нажатий — то вас проклянут

    а если где-то в меню будет сидеть настройка скорости автоповтора, чтобы каждый мог под себя подстроить, то вобще цены не будет.
    а для самолетной прошивки как раз все эти навороты в виде кривых в микшере или точек каналов ИМХО не нужны....
    дык тогда не парьтесь с выбором, кривая применяется изначально к органу управления (стик, переменник) и все. я сколько не думал не смог подобрать ситуацию, в которой нужна кривая (или набор точек) после всех микширований.
  30. Аватар для ВитГо
    Цитата Сообщение от Stepan_M
    Виталий тут еще какое дело, при сохранении файла, на старой прошивке, если при этом включен приемник модели - то на время сохранения сервы загоняят в крайние позиции и что неприятно канал газа тоже. Был у меня несанкционированный взлет когда менял параметры на модели.
    В другую ветку !
    здесь вторая версия !
  31. Аватар для ВитГо
    Цитата Сообщение от HikeR
    по меню ходить одиночными нажатиями вполне допустимо, однако если придется вдруг где-то поменять значение -50 на +50 путем сотни нажатий — то вас проклянут

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

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

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

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

    кстати, в микшерах иногда есть поле offset - в чем его математический смысл ? нужно чтото подобное делать ?
  32. Аватар для ВитГо
    все. сделал переписал обработчик чтобы он мог работать регистрируя и нажатия 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 - нет нажатия...
  33. Аватар для HikeR
    значит вопрос с кривыми решен - кривая всегда будет накладываться на входящее значение в микшер !!
    эээ... у вертов обычная схема - 3-й канал микшируется минимум на два других, собственно газ и общий шаг винта. кривые (или скорее набор точек) у них разные и привязаны к полетным режимам.

    предложенная схема учитывает этот момент? то есть не пойдет ли в разные микшеры одна и та же кривая (набор точек)?
    кстати, в микшерах иногда есть поле offset - в чем его математический смысл ? нужно чтото подобное делать ?
    дык это просто смещение после всех преобразований. боюсь ошибиться, но вероятно это можно представить себе как одновременно опущенные элероны для работы в качестве закрылков, но и для выполнения своей основной задачи.
    ну или смещение средней точки.
  34. Аватар для ВитГо
    все настройки будут построены по схеме реляционной БД..
    отдельно массив кривых, с индивидуальными номерами - которые указываются в микшерах.. таким образом разные микшеры смогут использовать одни и те же кривые (в первой версии прошивки кривые были привязаны к каналу и полетному режиму)
    либо наоборот разные микшеры разные кривые - даже если источник значения будет один (например в нашем случае thro)

    так пойдет ?

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

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

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

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

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

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

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

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

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

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

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

    применять RC-OS смысла не вижу.. итак памяти мало... тем более у нас же не 128ая мега, я все таки не оставляю надежды использовать только стандартную конфигурацию оборудования... а оставшееся место во флеш памяти использовать для хранения моделей.. в первой версии кстати свободно около 10 кб... - это еще около 30-40 моделей !! (но в первой версии этого кода нет.. хочу его написать для второй версии)
    Обновлено 01.10.2010 в 13:32 [ARG:5 UNDEFINED]
  37. Аватар для Aleksey_Gorelikov
    По поводу логики, которой нет ни у одного передатчика - есть еще что посмотреть... Старый, добрый мультиплекс серии профи 4000 .... Его функционал вроде бы никто не повторил, и несмотря на старость (сродни дерьму мамонтов) он досих пор уважаем и востребован в определенном (правда достаточно узком) кругу моделистов. А узкий круг наверное потому, что конфигурить его без компа - практически нереально, чтобы не запутаться в наворотах - надо все настройки долго обдумывать и записывать на бумажке. Ну и плюс (точнее минус) - то, что в силу его старости - проявляются болячки схемотехники. Энергонезависимой памяти тогда еще небыло, пзу - не знаю почему использовать не стали... Короче - прошивка у него лежит в статической озушке, которая питается от литиевой батарейки. Батарейки свое отживают, менять "на горячую" не все могут и эти передатчики вымирают.
    Но разговор не об этом. Рекомендую поискать на него инструкцию и посмотреть что он может. Возможно передрать что-то из него. Удачи!
  38. Аватар для ВитГо
    спасибо, обязательно гляну... (у меня уже коллекция всяких мануалов :-)) и действительно очень полезно их читать)
  39. Аватар для NVS
    Чувствую, начинается интересное и серьезное "кино"..... Задумки многообещающие...
    Что ж, хочется пожелать, чтоб все это реализовалось в "рабочую" версию...
  40. Аватар для Stepan_M
    очень ждем.