Самодельный передатчик (часть 1)
кривые можно, только не визуально. к примеру тот же MC-18 имеет экпоненты/миксеры и знакосинтезирующий дисплей, но это не пример для подражания.
графический дисплей от сотового - не такая уж редкая и дорогая вещь, найти можно.
Да на Сях ведь пишите …
я отчетливо понимаю что на ASM-е можно написать хоть чёрта на колёсика!
но не вижу ничего плохого в использании С(если я гдето грубо заблуждаюсь поправте пожалуйста),
и потом сейчас происходит развитие нескольких вариантов в конце концов у когото то что то получится лучше у другого хуже, и наоборот, а исходники на Сях по моему мого легче скомбенировать.
теоритически так и должно родится нечто… что пока история скрывает:)
ну как-бы… Си Сям - рознь. Если концепции построения программ разные, то порой может оказаться, что проще переписать, чем скомбинировать. Если речь идет об интеграции исходников - лучше сразу выработать единую концепцию и работать параллельно, а не диагонально. А тут есть пара затыков. Первый: каждый уверен, что его концепция наиболее верная, собственно потому и пишут каждый своё, а не развивают исходники, к примеру, фокуса. Второй: создание концепции - тоже процесс творческий, лично у меня сменилась уже четвертая 😃
Вывод: общую концепцию возможно выработать только в условиях коллектива, иначе лучше сразу похоронить мысль об интеграции исходников. Единственный вариант инреграции в этом случае: на уровне API отдлеьных модулей, к примеру стандартный API модуля миксера позволит линковать чужой миксер к своей прошивке.
Что скажет купечество ?
Что скажет купечество ?
лично мое мнение не претендующее на истину:
писать свой кодер начал после того как общарил “нет” и понял что то не найду то чего хотелось бы,
далее перечитал всё что смог найти по теме, сформулировал для себя ТЗ и начал работать…
подобным образом здесь по моему все поступают…
отсюда вывод что существование подобной темы с несколькими вариантами устройсв вполне обосновано и достаточно полезно!
это лирика, а теперь основная часть:
согласен по поводу API но не думаю что все сломя голову “метнутся” его придумывать и реализовывать,
потому что в реализации своих проектов все наверное преследуют какието свои цели и задачи.
есть маленькое предложение… Можно сделать так, чтобы микшеры, всякие другие функции подходили друг к другу. Надо каждую функцию выполнять в виде отдельной подпрограммы и договориться о формате входных-выходных даных
Надо каждую функцию выполнять в виде отдельной подпрограммы и договориться о формате входных-выходных даных
😃
НАДО!!!
давай догавариваться! 😃
как основоположник предлагай свой вариант, обсудим(у меня в этом месть на данный момент ваобщё пусто 😊, имею введу микшеры )
а ты говоришь “не метнутся”…
вот и замечательно! :)Тогда я составлю основной план. Выложу его. А потом вместе подкорректируем и переработаем.
первое, что предлагаю сделать - это надо пеоделить всю прогу на части, как собственно все и делают. Это блоки “Меню”, Генератора выходного сигнала, работы с АЦП, Математики(которая в свою очередь включает микшелы, экспоненты, кривые и т.д.). Также надо выделить отдельно подпрограмму работы с индивидуальными настройками модели.
Второе, что касается именно самой программы. Нужно стандартизировать основные процедуры и функции, имена и назначения переменных. Например те же самые графические процедуры хотя и имеют схожие имена, но все равно различны…
пока выкладываю свой изначальный вариант заготовки. Там почти ничего нету. только графический модуть. Файлы с перемеными и обозначениями… В архиве проект для кодевижна.
это было даже легче чем я думал 😃
😜
нехватает только второго джойстика и задней крышки 😎
Молодэц! А я завтра экзамен пишу… Бээээ!
Так что про общую концепцию? Подключайтесь! Я завтра продолжу… Просто щас времени не было…
вот фотки некоторые
Спасибо!
у меня кстати завтра тоже гемор-правда зачет ))
кстати есть у меня такая идея, не знаю правда насколько полезная фича получится, но все же…
есть у нас например 4 пропорциональных канала, то есть четыре выхода у приемника. Обозначим их как out0, out1, out2, out3. А положение ручек в формате in0, in1, in2, in3. Может микширование реализовать вот ТАКИМ образом:
______in0_____in1______in2______in3
out0__100_____0_______0________0
out1___0_____100______0________0
out2___0______0_______100______0
out3___0______0_______0_______100
это для случая когда по сути никакого микширования не происходит
______in0_____in1______in2______in3
out0__100_____0_______0________0
out1__20______80______0________0
out2___0______0_______100______0
out3___0______0_______0_______100
а это например когда ручка in0 влияет и на out0 и на out1
состояние канала определяется как “вклад” каждой ручки в процентах
Плата у тебя классная! заказывал где-то? а я решил пока из меги16 все выжать, а потом на 128 собрать новый передатчик (постепенно накапливаю опыт и новые идеи)
Плату я у знакомого заказывал…
А на счет микшера интереная идея… Надо подумать будет… Большая просьба к Vad64 рассказать немного о построении микшера… че-то я совсем не догоняю…я имею в виду
универсальный…
Плату я у знакомого заказывал…
А на счет микшера интереная идея… Надо подумать будет… Большая просьба к Vad64 рассказать немного о построении микшера… че-то я совсем не догоняю…я имею в виду
универсальный…
так по моему lamobot и описал упрощённый универсальный микшер?!
первое, что предлагаю сделать - это надо пеоделить всю прогу на части, как собственно все и делают.
Мысля мудрая, предлагаю такой вариант:
Интерфейс
- I/O интерфейса (кнопки, триммеры, крутилки)
- дисплей (драйвер с граф.примитивами)
- диалог (меню и страницы)
- шрифты (шрифты. ну можно объединить с “дисплеем”, если используется единственный матричный шрифт)
Модулятор - I/O модулятора (оси)
- формирователь/миксер (миксер = текущий из набора переключаемых)
- формирователь/протокол (протокол = текущий из набора переключаемых)
Общая часть - ресурсы (строки, картинки, данные)
- настройки (загрузка/сохранение глобальных настроек)
- модель (загрузка/сохранение изменяемых от модели к модели настроек)
представил бы всё это ввиде исходников, но словами понятнее.
представил бы всё это ввиде исходников, но словами понятнее.
а исходниками нагляднее 😊
вот что я имею на сегодняшний день
Большая просьба к Vad64 рассказать немного о построении микшера
Привет!
Собственно говоря, у меня микшеров-то и нет. Мне для моих моделей они были ни к чему и я не стал их реализовывать (и в то время не очень представлял, как это лучше сделать). Т.е. у меня в каждом канале (Элерон, Элеватор и т.д.) хардкодом задана единственная ручка управления. Также у канала есть признак реверса, расходы и задается кривая, по к-рой значение ручки переводится в выходное значение. Модель я здесь выкладывал и симулятор тоже. Оттуда должно быть понятно, что входит в модель и видно, как настройки влияют на выход.
В настоящее время я вижу ограниченность такого решения и вот что думаю: надо попробовать отказаться от предопределенных каналов. Т.е. в настройках канала задавать две или даже больше ручки управления с собственными кривыми. (И даже имя канала задавать в настройках). По-моему, этого должно быть достаточно для решения всех проблем. Главное - уметь строить канал из нужных ручек с собственными кривыми.
Такой подход утяжеляет работу с пультом. Но на все на это можно наложить визарды, к-рые будут создавать готовые заготовки для разных типов каналов - флапперонов там всяких, ССРМ и т.д.
а исходниками нагляднее 😊
исходники могу в личку (попусту сорить ими не хочется), но общие прЫнципы лучше все-таки обсуждать словами.
А я вот еще 4 тумблера воткнул в корпус… расходы отдельные на руддер элеватор и элероны… и еще на 3 оложения для переключения режима полета…
А я вот еще 4 тумблера воткнул в корпус… расходы отдельные на руддер элеватор и элероны… и еще на 3 оложения для переключения режима полета…
Кстати а никто не хочет попробовать датчики холла на джойстики?
будет вечная механика. Ccылок полно - любители ла-2 давно уже переделывают себе на такую.
Ccылок полно.
Ссылки в студию 😈