Самодельный передатчик (часть 1)
Апдейт прошивки через USB в этом проце - тоже с граблями. Что, если нужно устранить ошибку в самом обработчике USB или изменить дескрипторы или еще что-то? Единственный вариант тут, наверное, держать два обработчика - один в бутлоадере (без возможности обновления), а другой - для аппликейшна. Связь по USB, безусловно, классная фича. Но софтверное решение на AVR мне лично не нравится - извращение. Если бы я делал все с нуля, не стал бы на него закладываться. Также ломает решать любые лицензионные вопросы.
2 Vad64:
А как Вы смотрите на идею использования двух AVRов для решения подобных проблем? Не конкретно USB, а в принципе.
2 Vad64:
А как Вы смотрите на идею использования двух AVRов для решения подобных проблем? Не конкретно USB, а в принципе.
А зачем два АВРа, какие функции параллелить и как? У меня при максимальной загрузке (формирование Futaba РСМ1024) есть еще запас производительности, процентов 50. В режиме РРМ запас вообще многократный. Причем поскольку выходной сигнал формируется по прерыванию, я уверен, что никто эту задачу не притормозит. Мне кажется, мощности одного АВРа вполне достаточно для реализации базовых функций передатчика. А если надо, проще взять более мощный процессор.
Запас не вечен, когда-нибудь иссякнет 😃 А параллелить на мой взгляд стоит, как тут уже вроде предлагалось, рилтайм и не-рилтайм части. Т.е. грубо говоря “АЦП/миксер/формирователь” и “UI/другие интерфейсы/прочие рюшечки”.
Апдейт прошивки через USB в этом проце - тоже с граблями. Что, если нужно устранить ошибку в самом обработчике USB или изменить дескрипторы или еще что-то? Единственный вариант тут, наверное, держать два обработчика - один в бутлоадере (без возможности обновления), а другой - для аппликейшна.
Как я когда-то писал в личной переписке, именно так и сделано у меня. Загрузчик размещается в boot area флэша и совершенно автономен и защищен фьюзом от стирания и модификации, получает управление по BOOTRST (также фьюз) и имеет собственный дескриптор. Таблица векторов прерываний также при работе бута перемещается в соответствующую область. Так что проблема надуманная (“А если надо устранить ошибку в масочном ПЗУ загрузчика” - мы в более выигрышном положении).
Связь по USB, безусловно, классная фича. Но софтверное решение на AVR мне лично не нравится - извращение. Если бы я делал все с нуля, не стал бы на него закладываться.
Все профессионалы так считают. Но если говорить о народной аппаратуре, то AVR все же более популярен, а варианты с аппаратным USB достаточно куцые по остальным возможностям (я про AVR). В данном случае решение “дешевое и сердитое”.
А еще профи против использования кооперативных RTOS, хотя в данном случае опять же все очень красивенько ложится в рамки той же jacos, бесплатной, кстати.
Также ломает решать любые лицензионные вопросы.
Вопрос один: лицензия требует публикации схем и исходников в интернете. Если аппаратура - “народная”, то так и есть. А если код закрыт, то другое дело.
Привет Всем!
Читал, читал, устал. Может модулятор всеж ктото напишет? А то Фокус в одиночестве пучится и экзамены сдает.
Может модулятор всеж ктото напишет? А то Фокус в одиночестве пучится и экзамены сдает.
я пишу…
вот прямо сейчас и пишу …
недели через 2 думаю будет более менее рабочая прошивка…
Да на Сях ведь пишите и все равно каждый сам себе. Объединили бы усилия и быстрее бы дело пошло.
ну а как тут объединятся если у нас на текущий момент разные схемы (хотя и похожие) и разные экраны (у меня знакосинтезирующий)?! )) получается что ктото должен отказатся от своих текущих поделок и сделать заного.
от знакосинтезирующего однозначно стоит отказаться.
в принципе получается даже с ним неплохо
только вот никакие кривые не задать и триммеры графически изображаются прогрессбарами
былы бы возможность поставить хороший графический а бы его поставил 😉
кривые можно, только не визуально. к примеру тот же MC-18 имеет экпоненты/миксеры и знакосинтезирующий дисплей, но это не пример для подражания.
графический дисплей от сотового - не такая уж редкая и дорогая вещь, найти можно.
Да на Сях ведь пишите …
я отчетливо понимаю что на ASM-е можно написать хоть чёрта на колёсика!
но не вижу ничего плохого в использании С(если я гдето грубо заблуждаюсь поправте пожалуйста),
и потом сейчас происходит развитие нескольких вариантов в конце концов у когото то что то получится лучше у другого хуже, и наоборот, а исходники на Сях по моему мого легче скомбенировать.
теоритически так и должно родится нечто… что пока история скрывает:)
ну как-бы… Си Сям - рознь. Если концепции построения программ разные, то порой может оказаться, что проще переписать, чем скомбинировать. Если речь идет об интеграции исходников - лучше сразу выработать единую концепцию и работать параллельно, а не диагонально. А тут есть пара затыков. Первый: каждый уверен, что его концепция наиболее верная, собственно потому и пишут каждый своё, а не развивают исходники, к примеру, фокуса. Второй: создание концепции - тоже процесс творческий, лично у меня сменилась уже четвертая 😃
Вывод: общую концепцию возможно выработать только в условиях коллектива, иначе лучше сразу похоронить мысль об интеграции исходников. Единственный вариант инреграции в этом случае: на уровне API отдлеьных модулей, к примеру стандартный API модуля миксера позволит линковать чужой миксер к своей прошивке.
Что скажет купечество ?
Что скажет купечество ?
лично мое мнение не претендующее на истину:
писать свой кодер начал после того как общарил “нет” и понял что то не найду то чего хотелось бы,
далее перечитал всё что смог найти по теме, сформулировал для себя ТЗ и начал работать…
подобным образом здесь по моему все поступают…
отсюда вывод что существование подобной темы с несколькими вариантами устройсв вполне обосновано и достаточно полезно!
это лирика, а теперь основная часть:
согласен по поводу API но не думаю что все сломя голову “метнутся” его придумывать и реализовывать,
потому что в реализации своих проектов все наверное преследуют какието свои цели и задачи.
есть маленькое предложение… Можно сделать так, чтобы микшеры, всякие другие функции подходили друг к другу. Надо каждую функцию выполнять в виде отдельной подпрограммы и договориться о формате входных-выходных даных
Надо каждую функцию выполнять в виде отдельной подпрограммы и договориться о формате входных-выходных даных
😃
НАДО!!!
давай догавариваться! 😃
как основоположник предлагай свой вариант, обсудим(у меня в этом месть на данный момент ваобщё пусто 😊, имею введу микшеры )
а ты говоришь “не метнутся”…
вот и замечательно! :)Тогда я составлю основной план. Выложу его. А потом вместе подкорректируем и переработаем.
первое, что предлагаю сделать - это надо пеоделить всю прогу на части, как собственно все и делают. Это блоки “Меню”, Генератора выходного сигнала, работы с АЦП, Математики(которая в свою очередь включает микшелы, экспоненты, кривые и т.д.). Также надо выделить отдельно подпрограмму работы с индивидуальными настройками модели.
Второе, что касается именно самой программы. Нужно стандартизировать основные процедуры и функции, имена и назначения переменных. Например те же самые графические процедуры хотя и имеют схожие имена, но все равно различны…
пока выкладываю свой изначальный вариант заготовки. Там почти ничего нету. только графический модуть. Файлы с перемеными и обозначениями… В архиве проект для кодевижна.
это было даже легче чем я думал 😃
😜
нехватает только второго джойстика и задней крышки 😎