Самодельный передатчик (часть 1)
Кстати, смотрю на варианты схем - даже кварцы стоят по 12MHz. Но почему в этих схемах никто не нарисовал подключение PC по USB? Ведь это - пара мелких деталей при таком раскладе.
у меня это заложено(софтовый USB-) в атмеловских апноутах это есть ,
планируется что он будет подключён вместо UART -a. возможно и шить через него получится
а вот ссылка на софтовый USB
а ссылочку на что-то подобное? в частности на софтверный USB-лоадер, для примера.
На что-то подобное - на что именно?
- Редактор кривых - частный случай конфигурирования по USB. Я это делал для других проектов.
- См. выше. Реально есть возможность читать и писать блоки данных по USB - значит, можно что угодно конфигурировать и чем угодно управлять.
- См. rcdesign.ru - USB адаптар передатчика на ATmega8.
- Аналогично первым двум пунктам.
В целом, есть прекрасный программный USB драйвер с открытыми исходными текстами. Для данных задач его более чем достаточно. Если делать устройство, как HID, то писать драйвер на PC тоже не надо - Windows определяет устройство автоматически. Остается только написать утилиту конфигурирования или управления.
Что касается пункта 5 - загрузчика, то я реализовал такой для ATmega32 и выше (нужен бут-блок размером от 4-х килобайт, так как весь код написан на C). Он реализован также как HID устройство, поддерживает шифрование прошивок, обновление версий по тому же USB с помощью утилиты с PC, и ряд специальных функций. То есть, я вполне аргументированно могу утверждать, что это возможно, так как сам им пользуюсь для своих поделок. В процессе работы над ним был найден (и исправлен в сотрудничестве с автором usb-drv) ряд ошибок в упомянутом драйвере, добавилась функциональность и родился его порт для компилятора IAR, который стал частью официальной версии (см. оригинальное readme драйвера).
Однако, такой boot - это закрытый проект, поскольку делался не для данной темы. Потому я только упомянул, что такое возможно, но не имею возможности привести пример в виде ссылки. Это не исключает того, что кто-то напишет аналогичный. Знаю точно, что, как минимум, еще один человек пишет такой, но сам с ним не общался.
Так что предусмотреть надо однозначно - есть и пины свободные, и кварц подходит оптимально.
у меня это заложено(софтовый USB-) в атмеловских апноутах это есть ,
планируется что он будет подключён вместо UART -a. возможно и шить через него получится
а вот ссылка на софтовый USB
Советую обратить внимание на ту ссылку, что дал я. Драйвер от Objective Development не сравнить с первым таковым от Игоря Цеско (автора упомянутого аппноута атмела). Он написан на C под GCC/WinAVR (кроме time-critical секций, написанных на ассемблере), имеет открытый исходный код с гуманной лицензией и полностью документирован, включая особенности и ограничения. С ним основной код пишется на раз два, вот так, к примеру (кусок из кода адаптера RC аппаратуры к схеме с rcdesign):
//
// Execution starts here
//
__C_task void main(void)
{
wdInit(); // initialize watchdog timer
usbInit(); // initialize USB driver
bootInit(); // initialize boot loader interface
inDecoderInit(); // initialize input decoder
usbDeviceConnect(); // connect USB device to the bus
__enable_interrupt();
while (1)
{
wdReset(); // reset watchdog timer
inDecoderPoll(); // poll for input data
outSendData(); // return data via USB Interrupt In endpoint
usbPoll(); // process USB requests
#if BOOT_SUPPORT_ENABLED
if (bootRequest()) // jump to boot loader if switch is pressed
{
usbDeviceDisconnect(); // disconnect the USB device from the bus
inDecoderStop(); // stop the input decoder interrupts
bootJump(); // jump to boot loader
}
#endif
}
}
А вот, собственно, всё, что необходимо и почти достаточно (не считая формирования блока данных и HID Report Descriptor’а) для обработки USB запросов HID джойстика. Не правда ли, куда менее cryptic, чем ассемблерные варианты? Да к тому же еще и обработка USB данных в этом драйвере выполняется в реальном времени, а не после приема в буфер. Ровно 8 команд на бит - интересная статья о том, как это удалось, есть на сайте автора драйвера.
//
// USB setup request processing
//
uchar usbFunctionSetup(uchar data[8])
{
usbRequest_t *rq = (void *)data;
if ((rq->bmRequestType & USBRQ_TYPE_MASK) == USBRQ_TYPE_CLASS)
{
// Return the report if host requests it without USB interrupt
if (rq->bRequest == USBRQ_HID_GET_REPORT)
{
// wValue: ReportType (highbyte), ReportID (lowbyte)
// we only have one report type, so don't look at wValue
usbMsgPtr = usbBuildReport();
return sizeof(usbReport);
}
}
return 0;
}
//-----------------------------------------------------------------------------
//
// Check if the USB Interrupt In point buffer is empty and return
// the data buffer for the following host request via USB interrupt
//
void outSendData(void)
{
if (usbInterruptIsReady())
{
// fill in the report buffer and return the
// data pointer (Report ID is not used)
usbSetInterrupt(usbBuildReport(), sizeof(usbReport));
}
}
Все это здорово конечно… но, коль скоро разговор вернулся в конструктивное русло, давайте не будем распыляться. Эта “рюшечка” по сложности и требованию к ресурсам не далеко уходит от самого передатчика. Лучше направить усилия на создание того, что мы, собственно, собираемся ей конфигурировать 😃
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 модуля миксера позволит линковать чужой миксер к своей прошивке.
Что скажет купечество ?