Самодельный передатчик (часть 1)
Все это здорово конечно… но, коль скоро разговор вернулся в конструктивное русло, давайте не будем распыляться. Эта “рюшечка” по сложности и требованию к ресурсам не далеко уходит от самого передатчика. Лучше направить усилия на создание того, что мы, собственно, собираемся ей конфигурировать 😃
2 osnwt:
Очень ценная и дельная информация, жаль немного преждевременная 😦 Хотя было бы здорово, если бы кто-то, руководствуясь ей, начал бы, как Вы говорите, отдельный проект по реализации конкретно этой фичи 😃
С софтверным обработчиком USB есть вот какие грабли - хост может подвесить контроллер на произвольное время, не говоря уж о проблемах с другими критичными прерываниями. Так что управлять моделью с подключенным хостом я бы не стал совершенно точно :о).
Вообще, применение софтверного USB для сложных real-time систем мне представляется малоперспективной затеей. Тем более, что уже достаточно недорогих контроллеров с аппаратной поддержкой USB. Мне, например, очень понравилось работать с AT91SAM7S64 - 64 кб флеш, 16 кБ ОЗУ, ARM ядро, отличная периферия и честный full-speed USB. По цене сравним с ATmega64.
Очень ценная и дельная информация, жаль немного преждевременная 😦 Хотя было бы здорово, если бы кто-то, руководствуясь ей, начал бы, как Вы говорите, отдельный проект по реализации конкретно этой фичи 😃
Информация как раз своевременная: надо закладывать интерфейс в железо. Пусть даже там пара деталек. При этом я ничего не говорил про реализацию фичи немедленно.
С софтверным обработчиком USB есть вот какие грабли - хост может подвесить контроллер на произвольное время, не говоря уж о проблемах с другими критичными прерываниями.
В принципе, при проблемах с хостом он точно может подвесить. Потому и рекомендуется ставить пуллап на int, чтобы не было дрожания инта при отключенном хосте и, соответственно, девайс мог работать автономно. Если хост без проблем, то он может подвесить не на произвольное, а на вполне документированное в драйвере время (которое, увы, больше того, что можно позволить себе в реалтайме). Управление с хоста моделью - согласен, это больше из области теории. Но все остальное не является критичным в плане подвеса, а потому вполне имеет право на жизнь. Да, были проблемы с драйвером в ранних версиях, в т.ч. и в этом плане, но сейчас их не видно. Я достаточно много экспериментировал с ним в разных аппаратных конфигурациях, и он работает (медленно, но работает) даже там, где промышленное (фирменное) USB устройство (фотоаппарат Olympus) работать вообще отказалось (в определенной конфигурации аппаратуры).
Насчет SAM7 - да, я смотрю на него как на кандидата для своего парапланерного прибора. Мне лично все равно, на какой контроллер что писать. Но народный - это почему-то именно AVR. Потому я всего лишь сказал, что уже имея такой девайс, как предложенные схемы, просто смешно не сделать пары ног для USB. А будет ли этим кто-то пользоваться или нет - вопрос личного предпочтения. Я бы пользовался.
Не обязательно реализовывать одновременное функционирование USB и других функций передатчика. Можно сделать определение подключения компьютера при включении передатчика и далее две ветки: одна – работа с USB (апдейт прошивки, работа с моделями, режим симулятора), вторая – непосредственно передатчик с меню, настройками, и так далее. Определение может быть как автоматическое, так при помощи пользователя (зажать при включении кнопку, например).
Не обязательно реализовывать одновременное функционирование USB и других функций передатчика.
Именно так! Если запрещены прерывания от USB (Int 0/1), то драйвер ничем себя не проявляет и, соответственно, его функции не работают (и не мешают).
Ну, а автодетект сделать - вообще проблем нет. Ведь с USB поступает также +5 вольт. Достаточно увидеть присутствие их на схеме, и можно, во первых, питать от этого источника при работе без ВЧ. Во вторых, в текущей версии драйвера добавлены функции usbDeviceConnect()/usbDeviceDisconnect() (при наличии аппаратного соединения пуллап-резистора не с плюсом, а с пином). То есть, увидели +5 вольт на шине - выдали usbDeviceConnect(). А до того никто никого не повесит, так как хост вообще не будет считать, что подключено какое-то устройство.
В общем, вариантов множество.
Апдейт прошивки через 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 но не думаю что все сломя голову “метнутся” его придумывать и реализовывать,
потому что в реализации своих проектов все наверное преследуют какието свои цели и задачи.
есть маленькое предложение… Можно сделать так, чтобы микшеры, всякие другие функции подходили друг к другу. Надо каждую функцию выполнять в виде отдельной подпрограммы и договориться о формате входных-выходных даных